Netlify-cms: Migrate to plain (post-processed) CSS

[erquhart]

The CMS has a number of conflicting CSS architectures in place. Up until now we've loosely expected to settle into CSS modules. The problem with CSS modules is they're still just static CSS, and they still have to live in their own file (ideally per-component).

Styled components is getting pretty mature, and would allow us to house (dynamic!) styles right in our component files. It supports theming, too.

Let's discuss!

---

Update

Plain ol' CSS is really seeming like the right approach. This ticket is being updated to cover migration to plain CSS (with cssnext for future syntax support). Note that multiple contributors can collaborate to make this happen.

[Benaiah]

I've been reading up on styled components ever since @rafaelconde mentioned them to me the other day, and I really like the concept. The ability to use ${ <js expression> } in the CSS so you can update styling based on props sounds really powerful, and I like that we'd be able to keep the CSS and JS together in the same file. My main concern is what the tooling experience is like using styled-components - if people are able to adapt to it fairly naturally then I think it's a great option. I'd definitely like to hear from others what their thoughts are towards it as well - @calavera, @biilmann, and @josephearl in particular.

[niksurff]

My quick 2 cents as I'm browsing through the issues and just had to make a similar decision. :octocat:

I very much like the styled-components API. My only grime is writing CSS in JS template literals. It makes linting and syntax highlighting not trivial especially in an OS project where you can expect changing contributors with varying editors.

I suggest checking out glamorous. It's API is kept very close to that of styled-components, but styles are written in plain JS objects. 👍

[Benaiah]

@nikvm glamorous looks cool, and you're right about linting/highlighting styled-components not being as easy as regular CSS. It is more verbose, but the syntax highlighting problem is somewhat better (though it's not being highlighted as CSS, but as an arbitrary JS object), and I also like that it doesn't require you to ship a CSS parser to the browser. It also seems like it'd be easier to do custom preprocessing of glamorous styles, as they're already POJOs. Do you know of any tooling for linting glamorous styles - ideally something that hooks into eslint?

[niksurff]

Actually, I think that's still an open issue generally for CSS in JS objects.

Have a look at this glamorous issue and this twitter thread. :octocat:

[erquhart]

@nikvm yeah, highlighting does matter. That said, fixing syntax highlighting by changing the syntax (objects instead of css) feels like a stick too big for the problem. Styled Components has a lot of momentum (so the community support is a plus) and syntax highlighting plugins that will cover a whole lot of folks: https://github.com/styled-components/styled-components#syntax-highlighting

[erquhart]

Excellent breakdown on why not to use CSS-in-JS: https://reactarmory.com/answers/should-i-use-css-in-js. Bear in mind that CSS modules are unlikely to be a part of the picture moving forward.

[erquhart]

Note by @Benaiah from a recent planning session: a primary consideration is how this impacts extension authors. We want styling to be as painless and approachable as possible for them.

I'll also note that, at this point, I'm personally leaning pretty strongly toward good ol' CSS (using cssnext).

[tech4him1]

Another point is that the latest version (currently in beta) of react-toolbox is moving from Sass to PostCSS/cssnext, so we can get rid of Sass then (which should really help our install times as well): https://github.com/react-toolbox/react-toolbox/wiki/Migrating-from-version-1.3-to-2.0.

[tech4him1]

When we run the build on the CMS, we could also have the processor (PostCSS) check for namespace conflicts.