What do you think?

[olizilla]

I'm thinking about what our shared react component lib should look like, and this repo is a first pass at that. I'm also interested in what we use to build our shared components, what there public api is, and what are the requirements on the consumer for using them. Shared styling, i18n, and a sensible interface are the main concerns.

As a test, I've built out the footer that we need in the web ui and the ipld explorer, so this should have some value. I've built out two flavours of the same thing:

Styled components + styled system + rebass version:
https://github.com/olizilla/ipfs-react/blob/de4e4c8cdd184b6b60fcf62ef427263b4559ab40/src/footer/footer.styled.js

Tachyons version:
https://github.com/olizilla/ipfs-react/blob/de4e4c8cdd184b6b60fcf62ef427263b4559ab40/src/footer/footer.tachyons.js

And storybook is wired up to render them both out to: https://olizilla.github.io/ipfs-react/

The i18n is the same in both cases. Given we can pull in as many local resources as we want, we can have component level i18n (for composite components that have text in them, many won't). I'm totally open to other ideas on that, but the namespace per component looks like it would work well and may give the nice effect of only loading translations for components that are rendered.

The real trade off is around a global css dependency on tachyons & ipfs-css vs a css-in-js solution. Styled-components can be tweaked to change how it does the magic, but the gist is you write css for a component, and it creates a unique class name for those styles, and makes sure the style definition gets into the host page at runtime. This would allow us to publish components with no global style requirement.

The css in tachyons is all built ahead of time, and the classes are hardcoded, so a css-in-js soution is always going to be slightly heavier than it, but bundle size is a less critical metric for long term happiness than is feeling like we're using good tools that we understand. So I'm keen to get your thoughts. Are you happy with tachyons? Do you prefer styled-components? Does the styled-system magic make sense?

[alanshaw]

It's so great to see both these options side by side. My experience was that the Tachyons example was significantly less cognitive overhead than the styled-components example.

When looking at the tachyons example I thought:

• Was what is t?
• What styles do these terse class names apply?

When looking at the styled-components example I thought:

• What is t?
• What do these all these components translate to? Are they app components or stylistic components?
• What HTML elements do they map to?
• What props are available?
• Am I going to have to look up the appropriate component for every HTML element I want to put on the page?

I mean these questions are significantly effected by my experience as a developer. I'm super familiar with HTML so the tachyons example feels way easier to get up to speed with. Thinking about it, it's probably true of a lot of developers today.

I'm sure the styled-components is a breeze once you get used to it but I'm just observing here that the upfront cognitive load for someone new to it is much larger. I'm not saying that I dislike it or don't want to use it (IMHO it's pretty damn cool) but I feel first time developer experience should be well considered here.

[lidel]

:+1 for what @alanshaw said about cognitive overhead during initial onboarding.

There are also aspects of reusability and future-proofing hidden behind that, which is an additional value of going with tachyons+ipfs-css.

Being able to just copy class names of a specific part of UI and it will "just work" in other place/framework is a valuable feature: it makes it easier for people to reuse our visual language without using our component libraries, or even create components for their own framework of choice.

In the long run, I suspect that keeping abstractions light (html5+tachyons+ipfs-css) may translate to higher adoption of our visual language.

[olizilla]

@hacdias @fsdiogo I'd love to get your thoughts on this

[hacdias]

I mostly agree with @alanshaw and @lidel. Looking at both versions, the Tachyons' looks much better, much cleaner and much simpler to understand.

I think we could:

• Have Tachyons and IPFS CSS as peer dependencies so if one got updated, we wouldn't need to update it here. We could just leave a big version range except for major versions. The developer must import these two.
• Have a CSS file for this package since some components will need styling of their own. Not many, but if there is something specific, we'll need to do it and export it.
• JS files for components.

[fsdiogo]

I also agree that the Tachyons version will look easier for new developers, but I have to play the devil's advocate and say that for us, it happens partially because we're already familiar with the Tachyons approach.

When I started using Tachyons I didn't particularly like it, but now it has grown on me. In spite of that, sometimes Tachyons still feel a bit lacking for more complex styling. That's where styled components wins, it seems to have a steeper learning curve, but I believe in the end it would be worth it.

I strongly agree with @lidel that easy-to-use components will step up their adoption rate, so... ⚖️.

In conclusion, I'm happy with Tachyons but I wouldn't mind trying out the styled components approach.

[fsdiogo]

What I've used and think that works great is css-next with css-modules. It's an awesome combination but needs some webpack configs to get it working.

[olizilla]

@fsdiogo would you be up for adding an example footer component using those?

[olizilla]

I kinda agree that css-modules gets you alot of the scoping magic that styled-components gives. Also I heard that npm was using tachyon + css-modules to let them create composite selectors out of tachyons atomic ones, but the reference is lost in twitter somewhere.

[alanshaw]

@fsdiogo would you be up for adding an example footer component using those?

I'd be interested to see that ;)

[fsdiogo]

Will do guys 👍

[fsdiogo]

Here it is: #2

This approach isn't plug and play, i.e., in the app tha'll consume these components we must activate the CSS modules in its webpack config.

[hacdias]

@fsdiogo what if the consuming app doesn't use Webpack, just like IPFS Desktop?

[fsdiogo]

@hacdias we have to make a standalone build to be used by apps that aren't using bundlers.

[hacdias]

Nice then 😄