Emotion vs styled components

[lishine]

Would you please mention, what do you mean by

Why Emotion?
You can swap that out with styled-components or whatever you like, it's just important to use some kind of CSS-in-JS solution so that everything follows from the JS module dependency graph. Keeps your app maintainable in the long run.

I personally like emotion because it lets you apply class names to vanilla HTML elements. React is all about composition: you build simple components, compose those into more complex components, compose those into even more complex components. But at the lowest level, down to the metal, you should be able to see and read what the HTML is. You should see the DIVs and SPANs. With styled-components for example you never do.

Do you mean the css={{}} property?
Do you like then the theme-ui sx property?
I use chackra-ui, they do not accept sx, so I have to use Box, Text etc. I have to use some framework for accessibility matters...
What I usually do is wrap the component with some meaningfull locally name like -Layout, then it is easy to reason about the component.

[jp-simons]

Oh right, so there are emotion and @emotion/core which are two different packages. I like the former because it doesn't even care if you use React or not. The latter offers the css prop, but man, that's invasive! It has this @jsx comment which takes over your whole JSX pragma. I'd rather not let some CSS library have that much control over what's going on in my app! The JSX pragma is central to how React code transpiles into ES5.

[lishine]

I see now. They have two options - general and react.
Can you use theming with emotion ? I also like the styled-system shortcuts...

[jp-simons]

Sure, but that opens up a new can of worms in a multipage app. You'd basically have which theme as "request scoped" data, that is data depending on who's calling you. So lets say you have some auth middleware that looks up the user, you could have some other middleware that runs after that putting the current theme for that user in res.locals.

Then the question is how to make that available everywhere for every component to access. In a client-side only world it's easy because each user has their own execution environment (their browser), and you can just put it in a global variable. With server-rendered pages every request is sharing NodeJS global state, so you have to use Context.

Basically you'd go from res.locals to a top level prop to context. That's what the AUTO_LOCALS was intended to help with, it ferries res.locals values into top level props: https://github.com/johnnysprinkles/exact-template/blob/master/src/server/render.js#L13

Once there you can edit your src/components/app.js to shove that prop into context with the React Context API. Now it's available from any component with useContext or however.