/ Javascript

Gettin Sassy

A few months back I wrote a post about the exciting discovery that I might be able to handle my styling in React by simply composing Javascript objects. I left that post having declared my excitement but having not spent enough time with this in practice to be certain of my opinion. Well some time has passed and I have found recently that, while awesome, this simply created more work.

The primary reasons I was so excited about simply using objects to build my styles was that it felt like there was no context switch, I could easily co-locate my styles with their components and it was easy to reuse small collections of styles. Well it turns out that what this resulted in is a worse context switch where I was constantly thinking of what the css property looked like and then making sure that I was camel casing it properly to be recognized by React. There are also a host of things that you cannot do with inline css, like hover effects.

For awhile it was very easy to create a hover effects just using onMouseEnter and onMouseLeave functions on my components. However, as I streamline my component trees more and more I find that I often only have one stateful component which is then responsible for passing down my onMouseEnter and onMouseLeave functions to a host of presentational components. Inevitably I will miss a link somewhere in this chain and what I've now created is as system fragile to my own error.

Enter Sass

In that last post I linked to several libraries that have sprung up to make working with styles as objects more powerful. However, when I decided that it was time to bring in a new tool to make this all more manageable I decided to avoid these and learn Sass. Why? Because React isn't forever and it's not even all the time. I don't know what front end framework I might end up working with six or twelve months from now but I do know that Sass will still exist and it will work. And boy I'm glad I did! It awesome! :D

Setting up Sass in my react project workflow is as simple as adding a new loader to my webpack

{
  test: /\.scss$/,
  loaders: ['style', 'css', 'sass']
}

and bringing in the appropriate npm packages.

npm install --save sass-loader style-loader node-sass

That's it! With that in my bundling process I can now build .scss files for each component and import that style sheet to its component and those styles will be loaded in and made available only to the scope of that component just like my Javascript objects! So

import './styles/components/home';

will bring in the styles for my Home.jsx component which are housed in my Home.scss file. I can even co-locate my .scss with their appropriate .jsx files like I was with my JS object files. I ended up deciding not to do this as it confuses Webpack when two files have the same name. I don't mind popping over to the styles/ folder to make some changes as I work now that everything is broken out into smaller component specific files.

I could actually go on and on about all the great things Sass does. It allows me to compose styles out of smaller parts using @extends or @mixin. It has programmatic control flow with @if, @for and @each. It basically gives me a JS-lite to build my CSS with and I really dig it. At the end of the day I'm still not a designer and I find myself in a bit of discomfort if I have to style a blank page with no direction. But am an engineer and function does need form so I am happy to now have a way to engage with this part of the workflow in a way that is more fun by being logical, composable and very powerful.