State of CSS in Meteor

[nathantreid]

I’ll respond to both of these later today.

[arggh]

My config is here:
…

With the same config as above, except the globals defined in fileOptions instead, this doesn’t work as I thought it would:

// /client/styles/shared/input.m.css
.a {
  composes: b from ('./utils.m.css');
}

// /client/styles/shared/utils.m.css
.b {
  font-weight: bold;
}

I get this error:

Processing Step: CSS Modules / PostCSS compilation
Unable to compile /Users/arggh/Development/modulesapp/client/styles/shared/input.m.css
CssSyntaxError: postcss-modules-scope: /Users/arggh/Development/modulesapp/client/styles/shared/input.m.css:2:3: referenced class name "b" in composes not found
.a {
  composes: b from ('./utils.m.css');
  ^
}

/~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[arggh]

This was a handy starter-kit: https://cdn.rawgit.com/joeybaker/styleguide-css/a2a7f31c/decks/CSS-Modules.html#1

[nathantreid]

I’ve filed an issue for the Cannot convert undefined or null to object error.
The issue is occurring because you are using postcss-simple-vars with the globalVariables option and without specifying any configuration for the postcss-simple-vars plugin. That’s a scenario I hadn’t anticipated.
For now you can workaround the issue by supplying a fileOption to postcss-simple-vars; even an empty file will do:

"postcss-simple-vars": {
  "fileOptions": [
    "client/empty.txt"
  ]
}

[nathantreid]

If you’re still using SASS but specifying the global variable in the postcss-simply-vars configuration instead of the globalVariables field, I’m surprised it’s getting that far. I’d have expected it to error out when node-sass ran.
It sounds like PostCSS is experiencing issue compile utils.m.css, but isn’t spitting out an error for that. Can you create an issue on Github and if possible supply a reproduction repository?

I’ll have to push the animation example off to tomorrow since work ran late tonight. I do agree on the documentation / samples, though. I’ve started work on a non-React SCSS example. It’s very basic right now, though - just a conversion of my basic CSS demo: https://github.com/nathantreid/meteor-css-modules-demo-scss

[arggh]

For now you can workaround the issue by supplying a fileOption to postcss-simple-vars; even an empty file will do:

Thank you, adding an empty file (or actually just one of the files used in globalVariables) fixed the error.

I’m not entirely sure how, but soon after I got the composing to work as well.

I created an issue to Github with my thoughts on the process of adopting CSS Modules:

Issue: Documentation and warning message improvements

[arggh]

How would I accomplish this in the most elegant possible way using CSS Modules, Blaze (and possibly ViewModel if you’re comfortable with that)?

I ended up doing it with a helper like this:

import styles from './card.css';

Template.view.helpers({
   cardStyle() {
      return flipped ? styles.flippedCard : styles.card;
   }
});

  <div class="{{cardStyle}}">
   ...

.card {
   ...
}

.flippedCard {
  composes: card;
  transform: rotateY(180deg);
}

It’s ok I guess, though I’m keen to see a nicer way

[arggh]

Actually, I just realized that using CSS Modules, I can get rid of Semantic-UI, but keep the natural language with composes and achieve really atomic and reusable CSS like this:

.container {
   composes: left-aligned very-padded four-column grid from "../layouts.m.css";
}

Super excited!

Edit: Also, properly isolated so no more class clashes, which were almost certain if you tried to combine Semantic-UI with any custom or 3rd party CSS.

[arggh]

The most important thing I’ve wanted with SUI is not to just create a UI library that people can be used to build websites, but to promote a new way of thinking about writing front end code.

…

Generally the thing I want developers most to take away, even if they dont decide the framework is for them, is that there are other ways to think about constructing meaning through physicality, and that it is most effectively modeled around natural language (not the existing vogue in abstraction)

@jlukic , I guess you can already consider your “goal” with Semantic-UI accomplished in a sense

[quote=“arggh”]Actually, I just realized that using CSS Modules, I can get rid of Semantic-UI, but keep the natural language with composes and achieve really atomic and reusable CSS like this:
[/quote]

[nathantreid]

ended up doing it with a helper like this:

import styles from ‘./card.css’;

Template.view.helpers({
cardStyle() {
return flipped ? styles.flippedCard : styles.card;
}
});

<div class="{{cardStyle}}">
…

.card {
…
}

.flippedCard {
composes: card;
transform: rotateY(180deg);
}

It’s ok I guess, though I’m keen to see a nicer way

That’s pretty much how I would have done it, and I LOVE composition especially for pulling styles from frameworks like bootstrap as well as reusable application-wide styles like you posted. The only thing I’d have added to what you posted is the caveat that although this seems to be the official CSS modules way (one “class” at a time per element) I don’t adhere to this when I start to accumulate lots of variations on a particular element. For example, if I need to flip the card, or make it purple, or both:

.card {
   ...
}

.flippedCard {
  composes: card;
  transform: rotateY(180deg);
}

.purpleCard {
 composes: card;
 background-color: purple;
}

.flippedAndPurpleCard {
 composes: flippedCard;
 composes: purpleCard;
}

About the time I get to flippedAndPurpleCard I start to really think about how many variations there might be, and whether or not I’m better off composing them the CSS Modules way shown above or dynamically in my code (this was all typed directly on the forum, so although it’s based off of actual code it may not be 100% correct):

import styles from './card.css';

Template.view.viewmodel({
   cardStyle() {
     let styles = [styles.card];
     if (this.isPurple())
       styles.push(styles.purple]);
     if (this.isFlipped())
       styles.push(styles.flipped]);
     return styles.join(' ');
   }
});

.card {
   ...
}

.flipped {
  composes: card;
  transform: rotateY(180deg);
}

.purple {
 composes: card;
 background-color: purple;
}

[arggh]

I’m not entirely sure how, but soon after I got the composing to work as well.

@nathantreid, I read from the changelogs that you have implemented some sort of caching.

I’ve experienced rather strange quirks a couple of times. Just now I was trying to build a component using media queries, but the stuff inside the query wouldn’t get picked up in the formed class.

I was already 30 mins into reading how to use media queries with CSS Modules and baffled, tried something, tried something else, went back to original version and bam it suddenly just started working.

Any chance this could have something to do with the caching functionality? How should I manually purge the cache, does meteor reset work?

[nathantreid]

I’d like to think that’s not an issue with the caching, but if it is you can use the newly documented cache option to disable it.

I’d be surprised if it’s a cache issue, but it could be. The cache check uses a hash of your source file (generated by Meteor’s caching compiler package) + a hash of your package options to determine if a file needs reprocessed.
Anyways, if you continue to see this issue, please let me know.

Also, yes - a meteor reset will also reset your cache.

[arggh]

I can’t speak to much to the first, I’m quite biased and see no cons, but then I never liked BEM.

After making the switch on-the-go to CSS Modules and a few days of first hand experience, I’m really happy I switched I’d say I spent a few hours understanding the patterns, flow and syntax to be productive enough, which was gained back in the next few hours because of not having to write BEM class names anymore.

It feels like a missing piece of a near-perfect-stack has been found. I never could justify doing CSS-in-JS with all the quirks and issues (media queries for example). Meanwhile, CSS Modules sits in the middle, taking best of both worlds (or that’s how it feels) and is just pure awesome [*] .

[*] As long as you know the few no-can-do’s that can pretty easily be worked around

@nathantreid, thanks for making this package! I highly recommend it.

[arggh]

@nathantreid , right now my class names are like this even in production builds:

_client_modules_tools_guests__guests_m__primaryButton

Does CSS Modules -package support truncating this to something like button_15jfiefj2x in production builds?

[nathantreid]

Class shortening for production is on my list, but I haven’t implemented it yet. In case you’d like to more into it, the class name generation takes place here: https://github.com/nathantreid/meteor-css-modules/blob/master/postcss-plugins.js#L16

[nathantreid]

@arggh I just published nathantreid:css-modules@1.5.0-beta.1, which includes support for supplying a template string in the package.json:

"cssModules": 
  "cssClassNamingConvention": {
    "template": "some string"
  }
}

The template uses es6 template literal syntax, and has the following arguments available (examples use the class .world from the file client/hello.css):
scopedName: the default css class name (_client__hello__world)
path: the sanitized path to the css file (_client__hello)
originalPath: the unsanitized path to the css file (D:\projects\css-modules\demo-css\client\hello.css)
name: the class name (world)
hasha: a reference to the hasha package
shorthash: a reference to the shorthash package

To create hashed CSS classes, you could use one of the following templates:

"template": "${name}--${hasha(scopedName, {algorithm: 'md5'})}" // world--200da8ad03f9a588526a2fe8c1c3fe73
"template": "${name}--${hasha(scopedName, {algorithm: 'md5'}).substring(0, 5)}" // world--200da
"template": "${name}--${shorthash.unique(scopedName)}" // world--1etuHN

Custom template strings will be run through any replacers you have set up.

[edit] Forgot to mention I also added a way to create your own custom generator function (inspired by @akryum’s addons to his vue package). Create a new package in your app’s packages folder e.g. meteor create --package scoped-name, add it your app, and make it a build plugin (package.js):

Package.describe({
  name: 'scoped-name',
  version: '0.0.1',
  summary: '',
  git: '',
  documentation: 'README.md'
});


Package.registerBuildPlugin({
  name: 'scoped-name',
  use: [
    'ecmascript',
  ],
  sources: [
    'scoped-name.js'
  ]
});

Then set up your own generater function (scoped-name.js):

global.cssModules = global.cssModules || {};
global.cssModules.generateScopedName = function(exportedName, filePath, sanitisedPath) {
  return `abc-${exportedName}_${sanitisedPath}`;
};

Now your styles will look like: abc-world_client__hello.

Let me know what you think - I’m open to feedback!

[arggh]

Great! I’ll try it as soon as I get to my laptop

[arggh]

@arggh I just published nathantreid:css-modules@1.5.0-beta.1

I just checked out the repo on Github, happy to notice CSS Modules is evolving!

I’m facing a new problem that I wanted to ask @nathantreid 's opinion for, it’s related to theming:

Let’s say I have an app like Wix or Squarespace, where a user can create websites using simple building blocks like title or map or imageGallery.

Now, I want to support theming, so that the user can switch and toggle between different looks or even mix and match them.

My initial idea is to use a passed down (or shared) property to specify the selected theme’s name, eg. black or red. I could allow the user to define a global theme for the page, but also to override it on block level to mix themes.

How? Let’s say I have a building block called title.

• In the title.m.css file, I have a class for each theme like so:

.default {
   .title { color: grey; }
}

.black {
   .title { color: black; }
}

.red {
   .title { color: red; }
}

• In JS, retrieve styles like so:

import themes from './title.m.css';

themeClass() {
   const themeName = Template.currentData().theme || DEFAULT_THEME_NAME;
   return themes[themeName];
}

• In template code:

<div class="{{themeClass}}">
   <h1>Title</h1>
</div>

I did a quick POC and this seems to work just fine.

I really can’t think of any alternative way of achieving the same using CSS Modules. That worries me, am I missing something? Any ideas how you would do the same?

[nathantreid]

First off, thanks, because I just found/patched a SASS importing bug while replying to this.
I’m not quite sure what you’re asking. I see you’ve got a working example, but you’re worried about it. Could you explain why?
If I were doing switchable themes, I’d likely do something very similar, except I prefer to use SASS, so it’d look like this (assuming that my styles would end up being much more complex than in the example):
_variables.scss

$default: (
  textColor: grey,
);

$red: (
  textColor: red,
);

title.scss

@import '/imports/themes/_variables.scss';

@mixin styles($theme) {
  .title {
    color: map-get($theme, textColor);
  }
}

.default {
  @include styles($default);
}

.red {
  @include styles($red);
}

The JS would be the same as what you have.

[arggh]

First off, thanks, because I just found/patched a SASS importing bug while replying to this.

You’re most welcome

I’m not quite sure what you’re asking. I see you’ve got a working example, but you’re worried about it. Could you explain why?

CSS Modules is still a fresh concept for me!

I stumbled across a few different ideas regarding theming with CSS Modules and was perplexed by the implied difficulty of the problem, when it seemed quite simple to me. Probably my scenario just happened to be very easy.

I guess I just wanted to double check my ideas with someone who knows this stuff before I use the pattern above to write quite many lines of theming related code

Thanks for the input (and for the package)!