in rails by example you can link the stylesheets to specific views and if the app grows and you have different views with different stylesheets and similar class-names than there is (maybe) the reload between them and you have no conflict.
but, how is that in a single-page-app?
how do you make sure that you do not use a class-name that is already used in a other stylesheet / view?
namespaces?
or a little tool that checks the stylesheets and warns in that case?
the best would be if the IDE wold check for CSS-selectors. There is a issue on IntelliJ. You can vote for it, i think it would be a great help.
https://youtrack.jetbrains.com/issue/WEB-74
for me it seems that the next-steps will be:
Having Style-Sheets beside Template / Components (i am working with Module-Unification)
Have a Prefix, by example āpe-ā for the people-Template
Name of the Stylesheet is then: āpe-styles.scssā
All the Stylesheets are collected by ā@import āā¦/pe-styles.scssāā
All the classes which are defined in āpe-styles.scssā have the prefix āpe-ā
=> with that i have a overview for all prefixes in the main-stylesheet, by the import-steps and a manually namespacing.
For the Future i hope that IntelliJ insert the above mentioned inspector.
So there are lots of approaches to managing CSS, and thereās really no ābest wayā unfortunately, both in the broader SPA world and in Ember specifically. In my experience managing css is one of the things that is really hard well to do long term. Iām a little cynical about it though. Weāve had a lot of discussion around it recently at my company and mostly itās just shrugs.
That said there are some great tools in the ember ecosystem so while I canāt point to one specifically I can recommend a few and you can look at them and see what makes the most sense for you. Hopefully others can weigh as well.
There are a couple addons that deal with what I would call āauto scopingā of CSS. ember-component-css is great for components (and only components). Essentially what it does is automagically create unique classes for each component and apply the correct stylesheet, guaranteeing that the styles are scoped only to the component. ember-css-modules allows you to break up your styles to correspond with your js and hbs files, and it also provides the ālocal-classā mechanism for scoping your css. These save you the trouble of setting up all the sass imports and class prefixes manually (what we do at my company currently) and that helps keep the styles in sync with the other code. Iām not sure what the status of either of these is in terms of module unification though, especially since MU is changing/delayed.
It appears that youāre already using (or planning to use) sass but Iāll go ahead and note that in addition to ember-cli-sass and ember-cli-less and similar libs thereās also an addon for PostCSS which can be really nice for not only preprocessing but adding other plugins like autoprefixer, etc.
One thing which Iāll also pitch to you as a potential option is functional css. If youāre not familiar with it itās basically āutility class firstā CSS meaning instead of having separate stylesheets you just attach a bunch of utility classes to your HTML markup. Itās controversial but a lot of people (myself included) really love it. Tailwind is probably the most popular functional css lib and ember-cli-tailwind is a fantastic ember integration. This is purely anecdotal but IMHO it makes CSS a lot more fun and maintainable long term (removes the need to name things and keep separate stylesheets and so on). I just made a little demo app and slide deck recently to present to our engineering teams which you can take a look at if youāre interested (the slides are in slides.html, may need to clone the repo to see them correctly).
Anyway if you have any questions on any or all of the above let me know, Iād be happy to dive deeper into any of it.
Tailwind sounds interesting.
do i understand it right?:
you āwrapā parts of css in a kind of a āvirtual classā and you do the same in HTML. Then the classes you defined are inside a scope and are valid only within?
Well tailwind works very differently in that sense, itās almost the opposite extreme as in your classes arenāt scoped at all and your styles are shared EVERYWHERE. Tailwind classes actually look a lot like inline styles (though theyāre much better than inline styles for a number of reasons). Hereās an example from the tailwind docs:
Thereās no āscopingā in tailwind because itās a completely different way of writing CSS. It makes the traditional methods of CSS organization and āuniquenessā more or less unnecessary, because you donāt have stylesheets at all. Thereās nothing to āscopeā or āorganizeā. You simply attach styles directly to your markup. That said thereās nothing to stop you from using something like ember-component-css and tailwind together. There are times where you might need to add some ātraditionalā styles to something where Tailwind just wonāt suffice, but those times are pretty few and far between in my experience
Anyway then with ember-css-modules and ember-component-css you have mechanisms for enforcing CSS āscopeā because youāre managing your CSS in the more traditional way (actually having stylesheets). ember component css works more like how you just described, by generating a āwrapping classā that is unique and then auto-scoping the css. An example from the ember-component-css docs:
And ember-css-modules is pretty similar but uses the ālocal-classā attribute instead.
Anyway, ember-css-modules is probably most similar to what you were initially going for, and can save a lot of the work of manual sass imports and manual namespacing. I mostly mentioned tailwind as an alternative to the entire approach of traditional css management. There are certainly some caveats to functional css and some people just hate it, but it kinda sidesteps the entire necessity of a css management strategy to begin with. That was .a little rambly but I hope that all makes sense.
