Closed chrbala closed 4 years ago
@kitten might be able to answer this better, but to my understanding it's largely in the pursuit of scope isolation and preventing unintended collisions between components.
You're not going to see a css-in-js library that effectively achieves this goal unless they're desugaring to more of an atomic css-style output (which has its own problems.)
We care a lot of specificity, which explains why classes and rules aren’t reused. This is somewhat different between different CSS-in-JS libraries.
Some optimise these cases and treat identical rules as identical regardless of what they’re targeting. There are also atomic libraries that aim to reuse as much as possible.
styled-components falls into the third category, which may be somewhat of a strict and predictable approach.
Sets of rules for StyledComponents are injected in the order they’re defined in and in the order that the components are defined in. When a component is defined you can imagine a slot or index to be allocated in the background (which actually happens now in v5). The rules of a component that is defined after another can then never come before it. So ordering is kept very strictly, which prevents styling issues, where another one of your rules that is defined after another suddenly doesn’t take precedence anymore because it has been inserted before another.
Hope that makes sense ✌️
This is mostly a question, but could potentially be a feature request if it makes sense. Basically, I'm wondering why referential equal css aren't deduped in the stylesheets, as illustrated below:
styleTags renders to the following:
If the components are combined differently, only one CSS class is generated:
Results in
Is there something that prevents combining those css classes? I've looked around for other tickets on css class optimization and just found https://github.com/styled-components/styled-components/issues/351.
Tested with styled-components 3.1.6.