3 ms·

Not a FE dev, so this may be naive but CSS cascades which means these components may rely on external css state. How is that handled and still qualify as self-c

Not a FE dev, so this may be naive but CSS cascades which means these components may rely on external css state. How is that handled and still qualify as self-contained?

Spivak 8y ago
When you render your components, you do so in a Shadow DOM where CSS neither enters nor leaves. https://developers.google.com/web/fundamentals/web-components/shadowdom#styling https://developers.google.com/web/fundamentals/web-component...
tracker1 8y ago
In practice nested behaviors, or class/id selectors will conflict. The more you rely on generalized stylesheets the harder it is to maintain. I've been developing mostly web based applications for 23 years now (started before CSS). Centralized/shared CSS can work great in a content focused site. It works horribly in an application where component behaviors might share common terms, and potentially clash with natural naming for styles or nested definitions in particular. You only have to look at how most developers create hacky patches on top of Bootstrap, as opposed to using the source the way it was meant to be. CIJ is a much more sane approach to application components. Look at the material-ui component library for a great example (which uses react-jss). Being able to reuse configuration from a swappable theme has worked great in an application that may have differing configurations based on deployment.
- GordonS 8y ago
  I've been developing mostly web apps for a long time too, 17 years, and I disagree. Well, I agree that a single, massive stylesheet file becomes difficult to maintain very quickly, but that or component based CSS that eschews inheritance are not the only ways to go. Personally, I prefer to use Sass, logically separated into files - one with variables, another with global and general styles that are inherited, and then one for all buttons, one for all forms, one for all modals etc. I find this middle ground works well, keeps styles consistent, is DRY 'enough', and is easily maintainable.
  - Chyzwar 8y ago
    There are also CSS modules that are a middle road between CSS in JS and classic Sass stylesheets.
  - tracker1 8y ago
    Right now, the application I'm working on supports the following feature in terms of styling/colors. Baseline settings, per-deployment/client settings (app deployed to different clients with a differing configuration), app configuration post-deployment configurable settings application wide, and post-deployment configurable settings per user. With CSS in JS, I just have to deepmerge some objects (from JSON), and poof, it all just works. Without this it's either a rube-goldberg contraption that builds from styling on demand either from sass, or monkey patching styling. I've done large projects with JSS and CSS/SCSS. I'll take CSS in JS (JSS). Yes, the syntax is slightly more annoying, having to wrap selectors as strings, and wrap values as strings (mostly). Though, I can pass in values from both a theme (injected with the options above) as well as handle manipulation of values at the component (ex: padding: theme.spacing.unit * 2). It's got all of the advantages of SCSS and more. The difference is mostly syntax for keys. paddingLeft vs padding-left.

Not a FE dev, so this may be naive but CSS cascades which means these components may rely on external css state. How is that handled and still qualify as self-contained?

Spivak 8y ago

When you render your components, you do so in a Shadow DOM where CSS neither enters nor leaves. https://developers.google.com/web/fundamentals/web-components/shadowdom#styling https://developers.google.com/web/fundamentals/web-component...

tracker1 8y ago

In practice nested behaviors, or class/id selectors will conflict. The more you rely on generalized stylesheets the harder it is to maintain. I've been developing mostly web based applications for 23 years now (started before CSS). Centralized/shared CSS can work great in a content focused site. It works horribly in an application where component behaviors might share common terms, and potentially clash with natural naming for styles or nested definitions in particular. You only have to look at how most developers create hacky patches on top of Bootstrap, as opposed to using the source the way it was meant to be. CIJ is a much more sane approach to application components. Look at the material-ui component library for a great example (which uses react-jss). Being able to reuse configuration from a swappable theme has worked great in an application that may have differing configurations based on deployment.

GordonS 8y ago
I've been developing mostly web apps for a long time too, 17 years, and I disagree. Well, I agree that a single, massive stylesheet file becomes difficult to maintain very quickly, but that or component based CSS that eschews inheritance are not the only ways to go. Personally, I prefer to use Sass, logically separated into files - one with variables, another with global and general styles that are inherited, and then one for all buttons, one for all forms, one for all modals etc. I find this middle ground works well, keeps styles consistent, is DRY 'enough', and is easily maintainable.
- Chyzwar 8y ago
  There are also CSS modules that are a middle road between CSS in JS and classic Sass stylesheets.
- tracker1 8y ago
  Right now, the application I'm working on supports the following feature in terms of styling/colors. Baseline settings, per-deployment/client settings (app deployed to different clients with a differing configuration), app configuration post-deployment configurable settings application wide, and post-deployment configurable settings per user. With CSS in JS, I just have to deepmerge some objects (from JSON), and poof, it all just works. Without this it's either a rube-goldberg contraption that builds from styling on demand either from sass, or monkey patching styling. I've done large projects with JSS and CSS/SCSS. I'll take CSS in JS (JSS). Yes, the syntax is slightly more annoying, having to wrap selectors as strings, and wrap values as strings (mostly). Though, I can pass in values from both a theme (injected with the options above) as well as handle manipulation of values at the component (ex: padding: theme.spacing.unit * 2). It's got all of the advantages of SCSS and more. The difference is mostly syntax for keys. paddingLeft vs padding-left.