- Were there moments when you cried back SASS or vanilla CSS?
- In your react example, I see you created <Title> as styled.h1, but that's an awkward way of bootstrapping a component. Even if I used SC, I would still put the style information outside my component code in the same directory. At this point I don't see the benefit over doing something like:
The big win for me is if you're making an SPA, all the knowledge of the app state is already stored in JS (redux, or local state, or handed down as props if using React). So instead of toggling styles on a class, you just hand the state to the styled component, since it's just a function that returns css.
Toggling styles is a good question. I have sometimes multiple classes that have to work together. For example to open a panel, I use some translate/transform, different positioning. How do you compose different styles for a single component?
How do you deal with mobile, where sometimes I have to override dozens of declarations with media queries?
- No! I have not missed class name collisions and specificity wars at all, and I have enjoyed being able to dynamically adapt my styling as necessary.
- This ties into a broader point of having "style components" like <Grid /> and <Row />, which is a very nice way of working in React. styled-components (the library) simply takes that pattern and enforces it across your application. See style-components.com for links to some more resources about this pattern!
- In your react example, I see you created <Title> as styled.h1, but that's an awkward way of bootstrapping a component. Even if I used SC, I would still put the style information outside my component code in the same directory. At this point I don't see the benefit over doing something like:
What can SC do that regular CSS or SASS can't?