.request-pending {background-color: $yellow;}
.request-acknowledged {background-color: $green;}
* For one people using React already have there "html" (jsx) in their javascript. This is not necessarily a bad thing.
* Many people use React with a library called redux, which is a very simple state-container. They then break up their application into components and containers. The data in the redux store is one giant tree that contains the entire application's state. Sections of the state are connected to the containers, which have various components inside of them. These components are generally just a function of the properties that they are initialized with. All the business logic happens in redux, and all the presentational logic happens in the components, with the containers in the middle passing the data.
* Components are meant to be isolated, composable, reusable, and easily testable. As a result people began using css-modules so that the names of the style classes could be isolated per component and not pollute the global namespace. This is enough for most projects.
* CSS in JS is particularly useful when you are building a library of components that are meant to imported individually and/or used together. When building a library with the following goals:
1. Have a lot of quality components that are deeply customizable view various properties without having to directly override the style, but still allow styles to be overridden
2. Isolate the components and their styles from each other so that you don't have to import the entire library to use 1 component.
3. Make it easy to import and use them in your project.
CSS Modules would fit, except that they make importing the components much more difficult for the end user. They basically would need a webpack config and loader to import the styles. That or they would have to link the css on their own.
As a result you had libraries like Material-UI use inline styles for the entire library. This has its own disadvantages. Not all CSS properties are available inline, computing the styles on every render can be slower than having normal CSS, and it looks kind of sloppy when you see the end result. As a result people are creating or improving alternatives to inline styles such as Glamor, JSS, Styletron, and aphrodite.
I also don't want to bother with switching languages just to color a border or center align some text. Or have static styles in one place/language and dynamic styles elsewhere despite both setting up the exact same component. And when working as a designer I like seeing the style code literally right there along with the component nesting code, data handling logic, etc. (In my personal opinion, the real benefit of this comes when designing using an inline workflow similar to jsx-style, but that's an argument for among converts!)
From my perspective anyway, generating CSS from JS is just to get these benefits and more without various performance problems. It's a practical compromise given the reality of how browsers work in 2016 and our current tooling. It's treating CSS as something like a compilation target (because it's a standard which happens to already exist) rather than writing the "assembly code" by hand. If browsers provided other ways of interacting with their internal style structs or whatever like setting default styles through json or a special js file then a different solution might make sense---perhaps even one which gives whole new powers!
Just look at https://github.com/rtsao/styletron there's a whole "how to use it" page, but zero info WHY to use it. Not even a section about valid use cases.
IMHO SASS covers almost all cases of CSS "at scale".
> It seems like mixing the actual styles in with the JS violates separation of concerns and clutters up the actual logic.
It does not just seem like it... it does violate it for no good reason.
The implementation of a UI widget is ultimately a combination of CSS, HTML, and JS which are coupled to some degree, so by colocating them together, the component is easier to manage. But to do this effectively, you need some way to get around the global nature of CSS. CSS modules and CSS-in-JS are means of achieving this.
A good blog post about this topic is: https://medium.com/seek-developers/the-end-of-global-css-90d...
Absolutely right. I covered this in a blog post I wrote over a year ago (which still applies today): http://hugogiraudel.com/2015/06/18/styling-react-components-...
> Descendant and child combinators are unsupported
Are conditional applications of rules also unsupported, like `:hover` and media queries? That's a big deal in terms of runtime perf, too.
From the footnotes:
> The one area where this is useful is combining descendant combinators with pseudo classes, the most common use case being where hovering a parent triggers a style change in a descendant node. However, this behavior be implemented in JavaScript with event listeners and explicit state changes if needed.
The article only has compilation performance tests, and there's a small mention in the docs: How does Styletron affect render speed in the browsers?
Also, what tool are you using to convert existing CSS to JS objects?
[1] https://github.com/rtsao/styletron/tree/master/packages/benc...
I got the same idea, when I looked at javascript style sheets.
"We don't do inline styles, we generate classes!"
If they already generate, why not merge the whole stuff?
It was also built with the excellent Inferno.js [1] library to render static pages while also having a super fast full client-side app, kinda like what Gatsby.js [2] does with React.