Thoughts on robust CSS methodologies for big projects.

There has already been a lot said about ways to handle CSS in growing projects and as frontend development has been my career nomenclature for many years now it is something I’ve mulled over and had to practically implement more than just a few times already.

I think the best solution I’ve found, is react-css-modules. Unfortunately, it is rather deeply tied into the tech stack that it is built on.

Why I like ReactCSSModules

  1. All CSS is strongly coupled to the components it describes.
  2. Presuming 100% adherance to the methodology, there is no chance of unwanted styles creeping in.
  3. Because each file only contains the css for the component it is describing, it’s very easy to find where to make changes (or fix bugs)
  4. The possible downsides like code repetition can be averted with a few good tooling options (ala PostCSS) and gzipping the output.
  5. Closely follows the standard CSS/HTML implementation (implementation into the HTML code was as simple as using ‘styleName’ instead of ‘class’).
  6. Ease of use – there is very limited ‘brain-drain’ or cognitive load with no need for naming conventions (I’ve found naming components takes up a considerable amount of mental effort as well as time when building out any new components) or having to worry that my carefully named component conflicts with some other component built 6 months before.

This was the case with the previous project we worked on at Ekaya, where we were able to build everything mostly from the ground up, using a Node & React stack and (once we got it all setup and running) it was glorious.

when you can’t use the perfect stack…

However, our latest project is an inherited Rails behemoth which we’re now both refreshing the styling and building in new functionality and moving away from the standard Bootstrap-based component structure, which means that we will need to start relying on our own naming conventions & ‘framework’ going forward.

I had a look at the non-react version of cssModules, but it messes with the way CSS is added to the DOM a little too much for my liking, which has pushed me back to having to attempt to build out as much of the happy-sauce found in cssModules, but manually and ideally in a way that makes it easy for new devs to quickly get up and running.

What I need in a solution

As I consider a solution, I’m looking to ensure:

  • a solid naming convention – I’m leaning towards something BEM-inspired
  • the separation of CSS into SCSS files by component to reflect the code base as closely as possible
  • sane defaults to reduce cognitive load and ensure consistent styling across the app.
  • A balance between class names as style descriptors and class names as component definitions (think class=”button button-blue button-outline button-large button-no-drop-shadow” (Bootsrap-esque) vs class=”widget–stats–button-outline” (more BEM-like) )

And there are a bunch of things that will need some deeper consideration, like

  • the nature of the project means we need to handle theming,
  • Would need to work with the inherited Bootstrap framework where possible (Grid system, etc) and
  • Finding a way not to have it all devolve into css-soup in a month or two (or as soon as there’s more than just me working on the codebase).

That’s it (for now)

That’s as far as I’ve gotten in my thinking on it (well in a way that is communicatable), but this is definitely an ongoing journey, which I’ll keep posting on until I have some sort of usable solution…

Feel free to weigh in if you have any thoughts <3

Leave a Reply