Extract module functionality from loading

[geelen]

Been chatting with @markdalgleish about this, but I thought I'd put my thoughts down into an issue that was a bit more async-friendly (since he has a day job and so chatrooms aren't ideal).

I love the module mode for css-loader, I love the local-by-default idea, as well as being able to import other files & extend classes. But I think those things are being all tied together in the current implementation, and could be broken out, which would mean more flexibility, reuse, and ease-of-contributions.

Here's my suggestion:

• Define a series of PostCSS transform that take the currently-supported syntax and converts it. Taking the example off the home page.

Input:

:local(.continueButton) {
  extends: button from "library/button.css";
  background: red;
}

After parse-imports.js

:import("library/button.css") {
  button: __tmp_487387465fczSDGHSABb;
}
:local(.continueButton) {
  extends: __tmp_487387465fczSDGHSABb;
  background: red;
}

After localize-and-extend.js

:import("library/button.css") {
  button: __tmp_487387465fczSDGHSABb;
}
:export {
  continueButton: _13LGdX8RMStbBE9w-t0gZ1 __tmp_487387465fczSDGHSABb;
}
._13LGdX8RMStbBE9w-t0gZ1 {
  background: red;
}

These transformations each have a single responsibility, are easier to test & maintain, can operate on a single file at once and totally agnostic to Webpack/JSPM/Browserify. After this:

• Automatically attach those two PostCSS transforms in the same way importLoaders can be used.
• If css-loader?module is set and CSS Module mode is activated, add the plugin postcss-local-scope to translate .localName to :local(.localName), just as it was before.
• The current localisation/extension logic is adapted to look for the :import and :export primitives, and look for usages of temporary imported symbols (e.g. __tmp_487387465fczSDGHSABb) and replace them with the exports of another file.

---

So, this achieves a couple of things. It reduces the complexity of this project in particular, yet still presents the same interface to users of the module (:local and extends are always available, local-by-default is there in "module mode"). I can implement :import and :export for JSPM, and then we can share the CSS Modules syntax & plugins. I think it increases the chances of making CSS Modules a specification, since we'll have multiple loaders using it (more users) & be able to solve spec-level issues at the same time for everyone.

I'm happy to build these PostCSS plugins, and I think I could write a PR to include them as importLoaders. Getting :import and :export to work might be a bit beyond me right now.

From the reaction to both this project & Mark's blog post last week, as well as the discussions at CampJS and in chat rooms, people are really excited about this kind of functionality. I think this would make a good next logical step for the life of CSS Modules, and give it the best chance of being adopted globally.

Thanks!

[joshgillies]

Nice, and exactly what I'd like to see. I'm currently (after discussion with @markdalgleish over the weekend) aiming to develop a Browserify transform to accommodate CSS Modules. Having postcss-local-scope exist independent of css-loader would be of great benefit here. Definitely keen to see this happen, and happy to offer a hand where possible. 👍

[sokra]

I already discussed it with @geelen, we are doing this.

[knownasilya]

Yes please on the browserify transform, and splitting out the scope part. Share the love 😻

[necolas]

please could you bake in the option to disable imports, exports, and extends? i consider those anti-patterns (terrible for code complexity) and would like to prevent those from slipping into our code-base.

[ai]

I agree with @necolas. Loader should not became a many-in-one combine. We has many tools to do it.

[MoOx]

+1 for an option to disable imports, exports, and extends

[markdalgleish]

@ai I disagree, CSS Modules is offering something unique here.

AFAIK, CSS Modules are the only way to turn nested extends into multiple classes on an element. Historically, this has only served to bloat up your CSS.

[markdalgleish]

@necolas (honest question...) do you have a unique class for everything, with styles duplicated between classes?

[MoOx]

@markdalgleish For my concern no. Shared styles are just shared via a component. So no shared styles using extends.

[markdalgleish]

We've tried to push towards components for everything, but we still share low-level, building-block styles across classes for things like heading text style, since that sort of thing changes between breakpoints and we want our site to work without JavaScript.

[MoOx]

An options to disable import/extends should not be a big deal don't you think ?

[sokra]

Loader should not became a many-in-one combine.

Shared styles are just shared via a component.

CSS Modules are the only way to turn nested extends into multiple classes on an element.

An options to disable import/extends should not be a big deal don't you think ?

I agree with all of this. I think there is a missunderstanding what CSS Modules are.

Here is what they are NOT:

• They are not a one-to-many transform. extends doesn't change your CSS. One input CSS still compiles to one chunk of output CSS. Most importantly CSS Modules doesn't copy CSS rules from other modules. In fact while compiling one CSS Module referenced modules are not even read.
• You are not forced to use them. If you don't use import/export/extends, it doesn't have any effect on your CSS. (Of course we can also offer an option to disable it, if you really want it.)

---

Historically you may have written your components this way: (I assume you are already using local-scoped CSS, as this was not a discussion point)

/* buttons.css */
.buttonBase {
  border: 1px solid black;
  background: #999;
}
.buttonBase:hover {
  border: 2px solid black;
  background: #eee;
}
.bigButton {
  font-size: 200%;
}

/* MyComponent.css */
.signInButton {
  font-weight: 200%;
}

// MyComponent.js
import buttonStyle from "buttons.css";
import style from "MyComponent.css";

// (HTML layout) including this line
<button className={buttonStyle.buttonBase + " " + style.signInButton}>Sign in</button>

I interpreted @MoOx comment as he is doing it that way:

Shared styles are just shared via a component. So no shared styles using extends.

If you have two separate roles: developer and designer you could shared the responsibilities in this way:

• designer: MyComponent.css, buttons.css
• developer: MyComponent.js

Ok wait. What if the designer wants to use the .bigButton style from buttons.css for the Sign in button. That's propably his responsibility. But the fragment he need to change is in MyComponent.js:

- className={buttonStyle.buttonBase + " " + style.signInButton}
+ className={buttonStyle.buttonBase + " " + buttonStyle.bigButton + " " + style.signInButton}

---

Here CSS Modules come into play:

All extends does is to move the className part from MyComponent.js into the MyComponent.css. It does it with a syntax that looks similar to compile-to-css languages, but technically it's fundamental different.

Here the same component using extends:

/* buttons.css */
.buttonBase {
  border: 1px solid black;
  background: #999;
}
.buttonBase:hover {
  border: 2px solid black;
  background: #eee;
}
.bigButton {
  extends: buttonBase;
  font-size: 200%;
}

/* MyComponent.css */
.signInButton {
  extends: buttonBase from "button.css";
  font-weight: 200%;
}

// MyComponent.js
import style from "MyComponent.css";

// (HTML layout) including this line
<button className={style.signInButton}>Sign in</button>

(Four lines where changed: .bigButton { extends: buttonBase;, .signInButton { extends: buttonBase ..., the className line and I removed the import buttonStyles... line)

Now everything that concerns the styling is in the CSS file (and in CSS syntax) and layout is in the JS file.

Same question: What if the designer wants to use the .bigButton style from buttons.css for the Sign in button.

  .signInButton {
-   extends: buttonBase from "button.css";
+   extends: bigButton from "button.css";

---

Technically the resulting CSS and HTML is exactly the same. CSS styles are still shared by including mulitple class names in the HTML class attribute. Just the place where you insert the used shared class names has changed (In my optinion in a better way).

I could add a list of benefits, but I don't have time for this, so it's left as an (easy) challenge to the reader.

---

Also take a look at @gaearon's https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0

You propably can apply the same pattern to CSS Modules.

MyComponent.css is a smart style. buttons.css is a dumb style.

[ai]

@markdalgleish yeap, I mean only about extend and import. But even CSS Modules already exists in separated project ;).