You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
No context switching, the styles are in the same file as the component
Allows for easy deletability (if that's a word), in pure CSS files you can have the problem that you don't (always) know if you can uberhaupt delete the css or not
We still allow for nested styles like:
import{Button}from'./Button';constAccordion=styled.div` // We don't need to know which class `.Button` uses, in pure css we _do_ need to know which one${Button} { border: none; }`
We can do variables/theming (okay we can use scss/sass/less, but that's an extra step as well)
We only have to think about "single" names for BEM (Blocks, Elements, Modifiers)
We have seen in our codebases that the naming conventions was different throughout the months/years, now we kind of force the BEM structure implicitely
We don't allow for hacks, or styling tags directly, we need to define a className
- "hacks" might be a bit strange here, but out of lasyness we've seen styled css directly on tags and nested children div > * which is not that great for specifity.
The generated css tries to be the lowest specifity, because we need the ability to override it later (if that makes sense somehow, more context maybe be required)
Use case: we want to use the ease of development of styled components, but we're building a library instead of an isolated app. That's why we need predictable, deterministic classNames. The generated classnames are inspired by BEM.
constButton=styled.button('Button')` background-color: transparent; border: 1px solid black; border-radius: 2px; padding: .5em 1em; /** If there is a prop named disabled, and it is truthy */ disabled { background-color: grey; }`