css模块化_了解CSS模块方法

朱雀 2022-12-03 01:53 161阅读 0赞

css模块化

In the ever-changing world of front-end development, it is quite hard to find a concept that actually makes a difference, and to introduce it correctly enough so that other people are actually willing to try it.

在瞬息万变的前端开发世界中，很难找到一个真正有作用的概念，并正确地引入它，以便其他人实际上愿意尝试。

When we look at CSS, I would say the last big shift that happened in the way we write CSS (on the tooling side) would have to be the arrival of CSS processors, mostly [Sass][], probably the most well-known one. There’s also [PostCSS][], which has a slightly different approach but ends up essentially in the same basket – browser-unsupported syntax goes in, browser-supported syntax goes out.

当我们看CSS时，我想说(在工具方面)编写CSS的方式上发生的最后一次重大转变必须是CSS处理器的到来，主要是[Sass][] ，可能是最著名CSS处理器。 还有[PostCSS][] ，其方法略有不同，但最终却[落在][PostCSS]同一个篮子中–不支持浏览器的语法进入，不支持浏览器的语法消失。

Now a new kid has joined the block under the name [CSS Modules][]. In this article, I’d like to introduce this technique, tell you why it has some good points, and how you can get started with it.

现在，一个新孩子以[CSS Modules][]的名义加入了这个领域。 在本文中，我想介绍这种技术，告诉您为什么它有一些优点，以及如何开始使用它。

## 什么是CSS模块？ **(**What is a CSS Module?**)** ##

Let’s start with the explanation from the official repository:

让我们从官方存储库开始进行解释：

> A **CSS Module** is a CSS file in which all class names and animation names are scoped locally by default.
> 
> **CSS模块**是一个CSS文件，默认情况下，所有类名和动画名都在本地作用域内。

Now, it is a little more complex than that. Because class names are *scoped locally by default*, it involves some setup, a build process, and a bit of magic that is sometimes hard to grasp.

现在，它要复杂得多。 因为*默认情况下* ，类名是*在本地作用域的* ，所以它涉及到一些设置，构建过程和一些魔术，这些魔术有时很难掌握。

But eventually, we can appreciate CSS Modules for what they are: a way to scope CSS to a component and escape the global namespace hell. No more struggling to find a good way to name your components, because the build step is doing that for you!

但是最终，我们可以欣赏CSS模块的本质：一种将CSS范围限定到组件并逃离全局名称空间地狱的方法。 无需再为找到命名组件的好方法而费力，因为构建步骤正在为您完成这一工作！

## 它是如何工作的？ **(**How does it work?**)** ##

CSS Modules need to be piped in a build step, which means they do not work by themselves. See this as a plugin for either [webpack][] or [Browserify][]. It basically works this way: when you import a CSS file inside a JavaScript module (such as, but not necessarily, a [React][] component), CSS Modules will define an object mapping class names from the file to dynamically scoped/namespaced class names that can be used as strings in JavaScript. Allow me to illustrate with an example:

CSS模块需要在构建步骤中进行管道传输，这意味着它们无法自行工作。 将此视为[webpack][]或[Browserify][]的插件。 它基本上是这样工作的：在JavaScript模块(例如但不一定是[React][]组件)中导入CSS文件时，CSS模块将定义一个对象映射类名，该类名从文件映射到动态范围/命名空间的类名，从而可以在JavaScript中用作字符串。 请允许我举例说明：

Below is a very simple CSS file. The `.base` class does not have to be unique on the project as it is not the actual class name that will be rendered. It is just a kind of alias inside the stylesheet to be used in the JavaScript module.

下面是一个非常简单CSS文件。 `.base`类在项目上不必唯一，因为它不是将要呈现的实际类名。 它只是样式表中要在JavaScript模块中使用的一种别名。

.base {
      color: deeppink;
      max-width: 42em;
      margin: 0 auto;
    }

And here is how you would use it in a dummy JavaScript component:

这是在虚拟JavaScript组件中使用它的方式：

import styles from './styles.css';
    
    element.innerHTML = `<div class="${styles.base}">
      CSS Modules are fun.
    </div>`;

Eventually, this will generate something like this (when using it through webpack with the default setup):

最终，这将生成以下内容(通过默认设置通过webpack使用时)：

<div class="_20WEds96_Ee1ra54-24ePy">CSS Modules are fun.</div>

._20WEds96_Ee1ra54-24ePy {
      color: deeppink;
      max-width: 42em;
      margin: 0 auto;
    }

The way class names are generated can be configured to make them shorter, or to follow a specific pattern. It doesn’t really matter in the end (although shorter class names mean shorter stylesheets) because the point is that they are dynamically generated, unique, and mapped to the correct styles.

可以配置类名的生成方式，以使其更短或遵循特定的模式。 最终并没有什么关系(尽管较短的类名意味着较短的样式表)，因为重点是它们是动态生成的，唯一的并映射到正确的样式。

## 可能有效的担忧 **(**Possibly valid concerns**)** ##

So this is how it works. And now, you must be thinking “what on earth is this thing? I don’t even…”. Well, hold on! I hear you. Let’s tackle those concerns one by one, shall we?

这就是它的工作方式。 现在，您必须在思考“这是什么东西？ 我什至没有……”。 好吧，等等！ 我听到你了 让我们一一解决这些问题，好吗？

***It looks friggin’ ugly!***

***看起来很丑陋！***

That is true. But class names are not intended to be beautiful; they are intended to apply styles to elements. And this is precisely what they do, so I would argue this is not a valid concern.

那是真实的。 但是类名并不是要漂亮。 它们旨在将样式应用于元素。 而这正是他们所做的，所以我认为这不是一个合理的问题。

***It is a pain to debug!***

***调试很痛苦！***

As soon as there is a build step to do some processing on your stylesheet, it is a pain to debug. Sass is not any easier. This is why we have [sourcemaps][], which you can set up for CSS Modules as well.

一旦有一个构建步骤来对样式表进行一些处理，调试就很麻烦。 Sass并不容易。 这就是为什么我们有[sourcemaps的原因][sourcemaps] ，您也可以为CSS模块设置[sourcemaps][] 。

I would actually argue that despite the unpredictability of class names, it is not that hard to debug as styles are, by definition, specific to modules. If you know what module you are inspecting in the dev tools, you know where to look for the attached styles.

我实际上会争辩说，尽管类名具有不可预测性，但是调试并不难，因为按照定义，样式是特定于模块的。 如果您知道要在开发工具中检查哪个模块，就知道在哪里可以找到附加的样式。

***It makes styles non-reusable!***

***它使样式不可重用！***

Yes and no. On the one hand, yes, but this is actually the point: it ties styles to a component to avoid global styles leaking and conflicts. Which is a good thing, I’m sure you will concede.

是的，没有。 一方面，是的，但这实际上是要点：它将样式与组件联系起来，以避免全局样式泄漏和冲突。 这是一件好事，我相信你会承认的。

On the other hand, it is still possible to define global classes (with `:global()`) such as helpers which are preserved as authored, making style abstracting as easy as usual. These classes can then be used in your JavaScript components.

另一方面，仍然可以定义全局类(使用`:global()` )，例如保留为创作者的助手，使样式抽象像往常一样容易。 然后可以在您JavaScript组件中使用这些类。

:global(.clearfix::after) {
      content: '';
      clear: both;
      display: table;
    }

CSS Modules also have a way to extend styles from another module, which basically works the same way as `@extend` in Sass. It does not copy the styles but concatenates selectors to extend styles.

CSS模块还具有从另一个模块扩展样式的方法，基本上与Sass中的`@extend`相同。 它不复制样式，而是连接选择器以扩展样式。

.base {
      composes: appearance from '../AnoherModule/styles.css';
    }

***It needs webpack, Browserify or \[whatever\] tool!***

***它需要webpack，Browserify或\[whatever\]工具！***

This is the same way Sass needs to compile the `.scss` files to actual CSS, and PostCSS needs to process the stylesheets to make them compatible with browser-understood styles. The build step is already there anyway.

这与Sass将`.scss`文件编译为实际CSS的方式相同，而PostCSS需要处理样式表以使其与浏览器理解的样式兼容。 无论如何，构建步骤已经存在。

***Why are we even discussing this?***

***我们为什么还要讨论这个？***

Well, I am not entirely sure that in the future CSS Modules will stay the way they are currently, but I do think this is a sensible way to write styles. Having a massive global stylesheet is not suitable for large sites decoupled in tiny components.

好吧，我不完全确定将来CSS模块会保持目前的状态，但是我确实认为这是一种编写样式的明智方法。 拥有庞大的全局样式表不适合在很小的组件中分离的大型站点。

The unique namespace of CSS makes it both powerful and very fragile at the same time. Such a solution, be it CSS Modules or any future tool based on this idea, allows us to preserve the strength of style-sharing with global classes while making it a breeze to avoid naming conflicts with scoped styles. Win-win.

CSS的独特名称空间使它既强大又非常脆弱。 这样的解决方案，无论是CSS模块还是基于此思想的任何将来的工具，都使我们能够保留与全局类共享样式的优势，同时又轻而易举地避免了与范围内样式的命名冲突。 双赢。

## 入门 **(**Getting started**)** ##

As said above, you will need either webpack or Browserify to enable CSS Modules.

如上所述，您将需要webpack或Browserify来启用CSS模块。

### Webpack **(**Webpack**)** ###

Let’s start with the webpack version. In the `webpack.config.js`, add the following configuration to tell webpack to treat CSS files with CSS Modules:

让我们从webpack版本开始。 在`webpack.config.js` ，添加以下配置，以告诉webpack使用CSS模块处理CSS文件：

{
      test: /\.css$/,
      loader: 'style-loader!css-loader?modules'
    }

Right now it will inject styles inside a `<style>` element in your page. This is probably not what you want, so let’s make a proper stylesheet out of it thanks to the [extract text plugin for webpack][]:

现在，它将在页面的`<style>`元素内注入样式。 这可能不是您想要的，因此，感谢[webpack的文字提取插件][extract text plugin for webpack] ，让我们制作出合适的样式表：

{
      test: /\.css$/,
      loader: ExtractTextPlugin.extract('style-loader', 'css-loader?modules')
    }

That’s pretty much it for webpack.

对于webpack差不多。

### 浏览器 **(**Browserify**)** ###

I’ve only ever used Browserify through the command line, so it is a bit trickier I guess. What I did was add an [npm script][] to my `package.json` file, like so:

我只通过命令行使用过Browserify，所以我想这有点棘手。 我所做的是在我的`package.json`文件中添加了一个[npm脚本][npm script] ，如下所示：

{
      "scripts": {
        "build": "browserify -p [ css-modulesify -o dist/main.css ] -o dist/index.js src/index.js"
      }
    }

This tells Browserify to run on `src/index.js`, output `dist/index.js`, and compile a stylesheet at `dist/main.css` through the [css-modulesify][] plugin. If you want to add [Autoprefixer][] to it, you can complete the command like so:

这告诉Browserify在`src/index.js`上运行，输出`dist/index.js` ，并通过[css-modulesify][]插件在`dist/main.css`编译样式表。 如果要向其添加[Autoprefixer][] ，则可以像这样完成命令：

{
      "scripts": {
        "build": "browserify -p [ css-modulesify --after autoprefixer -o dist/main.css ] -o dist/index.js src/index.js"
      }
    }

As you can see, you can use the `--after` option to process your stylesheet after having it compiled.

如您所见，可以在编译后使用`--after`选项来处理样式表。

## 结论 **(**Conclusion**)** ##

As of today, the [CSS Modules][] system and ecosystem is a bit raw, as you can see from the Browserify configuration. But I am convinced it is going to get better as more people realize this is a sustainable solution for small to large projects.

到目前为止，从Browserify配置中可以看到， [CSS Modules][]系统和生态系统还有些粗糙。 但是我相信，随着越来越多的人意识到这对于小型到大型项目是一种可持续的解决方案，它将会变得更好。

I think the idea behind CSS Modules is the way to go. I am not saying this library in particular is the best solution available, but it definitely has some features with regard to the way CSS should be written: modular, scoped, yet still reusable.

我认为CSS模块背后的想法是可行的。 我并不是说这个库特别是可用的最佳解决方案，但是它在CSS编写方式方面肯定具有一些功能：模块化，限定范围但仍可重用。

As a further read, I recommend [this introduction to CSS Modules][] by Glen Maddern, creator of the project.

作为进一步的阅读，我建议项目创建者Glen Maddern [对CSS模块][this introduction to CSS Modules]进行[介绍][this introduction to CSS Modules] 。

> 翻译自: [https://www.sitepoint.com/understanding-css-modules-methodology/][https_www.sitepoint.com_understanding-css-modules-methodology]

css模块化

[Sass]: http://sass-lang.com/
[PostCSS]: https://github.com/postcss
[CSS Modules]: https://github.com/css-modules/css-modules
[webpack]: https://webpack.github.io/
[Browserify]: http://browserify.org/
[React]: https://facebook.github.io/react/
[sourcemaps]: https://www.sitepoint.com/using-source-maps-debug-sass-chrome/
[extract text plugin for webpack]: https://github.com/webpack/extract-text-webpack-plugin
[npm script]: https://docs.npmjs.com/misc/scripts
[css-modulesify]: https://github.com/css-modules/css-modulesify
[Autoprefixer]: https://github.com/postcss/autoprefixer
[this introduction to CSS Modules]: http://glenmaddern.com/articles/css-modules
[https_www.sitepoint.com_understanding-css-modules-methodology]: https://www.sitepoint.com/understanding-css-modules-methodology/