alanshaw
commented
6 years ago 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
propsare 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
olizilla
hacdias
fsdiogo
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?