This tool seems useful if you buy into the philosophy, but I'm just not sold yet - component based styling leads to a lot of style duplication and makes it very easy for a developer to go "off the playbook" when it comes to enforcing a consistent styleguide throughout an app.
The idea that "globals" in CSS are bad is counter intuitive to my experience that globals in CSS encourage consistency
Maybe when you're facebook size and you have many product teams all expected to produce something that all works together - I can see how the global namespace would be impossible to manage. For your average website or app? Not even close. It'll be awhile before you run into the limitations of CSS that Facebook is running into.
>This tool seems useful if you buy into the philosophy, but I'm just not sold yet - component based styling leads to a lot of style duplication and makes it very easy for a developer to go "off the playbook" when it comes to enforcing a consistent styleguide throughout an app.
You just handle it the same way you handle any shared code. You can keep files in a file scope, in a package / folder scope, or in the top-level global scope (in a small app that's totally fine). But removing globals-by-default removes a lot of "gotcha's" from working with CSS.
Globals are hard to name, so we use things like BEM [0] as a good naming convention to mitigate human error. CSS-in-JS is nothing more than an automatic BEM. I wrote down some thoughts on this today [1].
You should still use CSS and general programming best practices even if you define your styles in JS. For me, the big win is that I get access to proper variables, constants, dead code elimination, minification, template strings, destructuring, spreads, real computed values etc. out of the box and in an language I'm very familiar with as a programmer. That it eliminates half the build toolchain is also a plus.
In some of my projects I have 2 scopes: A framework scope and a component scope.
The framework scope has all the composeable classes and standard forms like lists, shadows, colors, grids, cards etc.
Then, when the framework doesn't cover everything, I use component scoped css to complete it, without having to worry about a naming scheme like BEM. It just makes things easier when you have css that is really only relevant to one component. Just like programming, I can always make the code abstract and move it up to the framework.
The idea that "globals" in CSS are bad is counter intuitive to my experience that globals in CSS encourage consistency
Maybe when you're facebook size and you have many product teams all expected to produce something that all works together - I can see how the global namespace would be impossible to manage. For your average website or app? Not even close. It'll be awhile before you run into the limitations of CSS that Facebook is running into.