Importing into CSS Module

[willmcclellan]

I'm wondering what method people are using for importing data into their CSS Modules. composes is great for extending/composing styles but what about data such as color variables or measurement defaults?

I had a look at the ICSS spec and the :import syntax (https://github.com/css-modules/icss#import) but it doesn't look suited to for this use case.

Are there any patterns/techniques other people are using for this?

[nkbt]

Why not do class names composition in the component instead and not add more side-effects to the css?

[andreypopp]

I'm also interested in this.

@nkbt not sure what side-effectful in sharing constants between modules

[nkbt]

css file includes something else from outside. It is not self-contained and pure anymore.

See this comment #21 (comment)

I believe this is the best approach.

[geelen]

Yeah, so ICSS could support arbitrary symbols, not just class names, which could be used for variables. The first thing we're going to use that for is for media queries to have first-class treatment in CSS Modules. I think we're going to lean on postcss-custom-media to do something like the following:

/* breakpoints.css (media queries are exported by default) */
@custom-media --small (max-width: 30em);
@custom-media --med (max-width: 60em);
@custom-media --large (min-width: 60.01em);

/* my-component.css */
@custom-media --small from "./breakpoints.css";

@media (--small) {
  /* styles for small viewport */
}

This isn't in place yet, but I'm working towards it.

Now, for variables, we could do something using postcss-custom-properties:

/* constants.css */
:root {
  --primary: rgb(248, 10, 10);
}

/* my-component.css - option 1 */
:root {
  --primary: primary from "./constants.css";
}

.foo {
  color: var(--primary);
}

/* my-component.css - option 2 */
.foo {
  color: var(--primary from "./constants.css");
}

But I'm not sure I like that so much. For one, the postcss-custom-properties is like a polyfill, but it's limited in what it can do (because the spec has runtime behaviour that can't be polyfilled). As such, I'm not sure how valuable it is to be using a cut-down version of the spec. But the bigger issue is the fact that I don't see a strong use case for variables at all with CSS Modules. Basically, with variables, you import a number, or a string, or a colour. With CSS Modules you can compose a class with the same number, string or colour and the context in which it's used. So, instead of:

.foo {
  color: var(--primary);
  border-radius: var(--small-border-radius);
}

you can just write:

.foo {
  composes: primary-color from "./colors.css";
  composes: slightly-rounded from "./borders.css";
}

So, in summary, special media query syntax 👍, variable support... probably not.

[nkbt]

I don't quite understand why add any kind of logic to css at all. We already have JS and can manipulate what and how we import and compose.

[geelen]

That's what I'm arguing for. Except there is no "composition" for media queries, so we add special syntax there.

[willmcclellan]

Thanks for the input, it certainly helps. Currently we're using a post-css plugin but it's global so kind of defies the point of modules.

I did experiment with composes but it's a little bit restrictive, in that to achieve this:

.foo {
  color: var(--primary);
  background-color: var(--primary);
  border-radius: var(--small-border-radius);
}

You would need this:

.foo {
  composes: primary-color from "./colors.css";
  composes: primary-background-color from "./colors.css";
  composes: slightly-rounded from "./borders.css";
}

That's a simple example that's starting to get a little convoluted, because the variable is tightly coupled to the style property. Maybe I'm thinking about it in the wrong way, but from a JS perspective this kind of thing would be trivial:

import colors from './colors'
import borders from './borders'

.foo = {
  color: colors.primary,
  background: colors.primary,
  borderRadius: borders.slightlyRounded
}

But yeh, this approach might not be ideal altogether because it makes the CSS too dependant. Perhaps we should be composing the themes-based styles outside of the CSS and passing them into components.

[geelen]

You can compose multiple classes on one line, which makes things a bit more descriptive if you pick good names:

.foo {
  composes: primary on-light from "./colors.css";
}

Here's another example, with just some names off the top of my head:

.bar {
  composes: alternate on-dark from "./colors.css";
  composes: light-rounded-border light-box-shadow-on-hover from "./borders.css";
  composes: tooltip top-right from "./layout.css";
  composes: fades-in-on-hover from "./effects.css";
}

[willmcclellan]

Ah, that's really nice. 👍

[nkbt]

There was a nice talk on React Europe https://www.youtube.com/watch?v=ERB1TJBn32c Separating your styles on visual and "state"-styles works pretty well for us. Visual are coming from css-modules, state-styles are done via js.

[geelen]

Gonna close this just to tidy up our issues. Feel free to reopen if you have further questions, @willmcclellan :)

[andreypopp]

I implemented an API to generate CSS modules out of JS which solves that problem. https://github.com/andreypopp/styling

It has a webpack loader which executes JS code during building and generates CSS modules from exported values. You can use JS to construct styling objects.

[serapath]

I was giving an example that has not much to do with the way css-modules work, but it gets the job done. See #23

In ICSS it says here

:import("path/to/dep.css") {
  localAlias: keyFromDep;
  /* ... */
}
:export {
  exportedKey: exportedValue;
    /* ... */
}

Maybe it's totally off, but what about something like:

:root {
  --myThemeColor1: blue;
}

 /* as in npm modules, but with the option to pass in some customizations */
:import('moduleName')(var(--myThemeColor1)) {
  localAlias: keyFromDep;
}
:export {
  exportedKey: exportedValue;
    /* ... */
}

Because it's nice to be able to import css and to choose what is needed, but how to adapt a certain css component with some styling that is custom to a specific project that is being worked on?
It would be a shame if a css module would define some kind of padding or font-size or color that cannot be switched to values needed in the current project.

Of course, once it's loaded into the project, I can always use javascript to adapt a specific styling to what i need in a given project, but it would be nice if the initial css can already be adapted.

Beyond that, it would even be nice, if there could be some kind of live updates

import styles from './App.css';
/* .... */
render() {
    return (
      <div className={styles.app}>
/* ... */
/* probably there is a nicer way to specify the API for that, but maybe something like: */
styles(styles.app).update('color', '#f00')