前几天我们开会讨论新项目的技术选型和项目结构，其中讨论到样式管理的部分，争论一下子多起来。前端样式，最终的表现还是css，但是在开发时，则会有多种多样的管理方式。之所以争论多，也是因为管理方式太多，不同的开发者想法不一致引起的。本文就来梳理一下在前端项目中样式的管理，以及表达我自己的样式管理方式。

理解css-loader

css-loader是我们在现代前端开发中必须掌握的一个东西，它给我们提供了css在前端开发中的一种工作模式，并且我们很多关于css的东西都基于此。

它功能主要是解释样式（css）中的import和url，并且把它们认作一个资源模块，用webpack的模块化方式require这个资源，完成这一步之后，在读取资源内容，并进行解析或转化。在读取的时候，它基于file-loader或者url-loader，因此，要了解读取资源内容这个步骤的原理，可以再深入去了解这两个loader。也就是说，在css-loader的作用下，就像js里面，你不断import一层一层的模块一样，css文件里面，也可以做到这样的效果。

但你需要理解css-loader的输入和输出，它的输入是css样式表（里面包含了import等），输出是将import的东西打包进来之后的css样式表（不再包含import），css-loader就是一个css的打包器。因此，在对scss/less/postcss等样式处理器的loader进行使用时，要把它放在css-loader之前运行（在webpack配置中放在css-loader之后）。而类似style-loader、extract-loader这样对css样式表结果进行后置处理的loader，则要放在css-loader之后处理。style-loader是将这些处理好之后的css样式表，用一个<style>标签包起来，直接（动态）插入到html文档中。

在css-loader是一个“css的打包器”的基础上，css-loader还是一个css语法的增强器。css-loader提供了css module的功能，即css in js，将css作为一个模块，导出css接口的形式。这非常适合jsx的开发模式，它不仅可以使使用方式更现代，而且还可以起到css的局部作用域效果。包括vue里面的scoped style也是这样实现的。但是实际上，css module是使得样式的类名随机化，并且在jsx里面使用的值到最后编译的结果是随机类名，这样就可以不冲突。但是，需要注意的是，同一个css module被引用到不同js module时，该css module输出的类名是一样的。此外，@import语法支持用~引用node_modules里面的模块。

集中管理 vs. 组件化管理

在项目中组织管理样式文件也是一个麻烦事。传统的开发模式将所有的样式文件集中放在一起，这样做的好处是样式复用非常方便，大部分ui框架就是在这样的管理模式下出现的。但是组件化开发潮流之后，将样式和组件文件放在一起的思想流行起来，进而不少人开始习惯将同一个模块的js和样式文件放在一起管理。

写这篇文章的时候，我并不能准确的说，到底哪一种更好，因为集中管理和组件化管理各有自己的道理。但是，我又不能用“根据实际情况选择适合自己的”这样的话来搪塞。

集中管理有自己的优势，所有的样式放在一个地方，通过文件名区分一个样式文件对应什么模块或组件，找起来也不慢。样式和组件并不一定要绑定在一起，如果直接在组件文件内引用样式，那么你在某个地方需要用另一套主题去渲染这个组件的时候就比较麻烦，所以，将组件和样式分离，用名称绑定在一起，也是一种非常好的选择。从各个方面来讲，集中管理样式文件没有明显的坏处。

组件化管理样式文件是一种新的习惯，它更多的是从模块管理的角度思考。一个模块/组件，包含了dom结构、样式，以及js逻辑代码。特别是受web-component的影响，vue发明了.vue文件，将模板、js、样式写在一个文件里面，这样一个组件就是一个文件，要了解一个组件的全部工作原理，不需要打开多个文件。但是很明显，组件的复用仅限于组件作为一个整体来复用，不能把里面的某个样式挑出来复用。

文本形式 vs. 模块形式

css module概念提出之后，并没有受到广泛的追捧。大部分项目仍然使用className字符串的形式引用样式。但在某些项目中，我尝试使用css module之后，发现绝对是比较现代化可接受的一种新形式。文本形式直接使用className会比较适合集中式文件管理，你需要提供所有的类名给开发者，让他们知道每一个类名，才能在代码中准确挑选className。你可以遵循BEM的样式名规范，方便开发者查找样式。

但是，css module的形式则不需要进行推测。也就是说，在使用过程中，开发者是根据你的css module导出的接口来进行使用，而非约定的className，这样对于开发者而言，他不需要去记忆和查阅既定的样式名，只需要像一个模块一样，使用模块导出的接口作为样式名。模块导出的接口，其返回值代表了实际的类名，但这个类名可能是一个随机字符串。

另一个值得关注的是，在react native这种形式的开发中，样式并不遵循web标准，所以在使用的时候，样式被以运行时的形式直接载入到程序进程中。所以，使用className的形式不是很符合这样的开发。当然，实际上，我们的构建工具可以帮助我们从样式中寻找出对应的className，并把样式在运行时进行载入，但这与react native推荐但形式差的有点远。

通用的样式管理和使用方法

这里指的“通用”是指跨平台、跨端，向后兼容。用一种方法去管理和使用样式，通过构建工具，使得同一套代码，能够适用于web、native、小程序的开发。

• 集中管理样式文件，使用有损的css标准子集撰写样式，“有损”主要是希望同一套样式可以适用于react native
• 采用css module的形式使用css类
• 发挥css-loader的compose能力，避免css多层选择器（css module仅适用单层选择器）
• 将css转化为Stylesheet Object后使用于react native中

之所以使用集中管理，而不是流行的组件化管理，是为了复用，我们通过文件名来区分不同的样式文件是关于什么主题的。这样，实际上，我们更容易在开发中对样式进行调整。而且，扁平化的集中管理会减少一个节点的样式分散在不同目录时进行修改的尴尬。

css转化为Stylesheet objects的方法目前还不是很多，我所找到的库有css-to-react-native、css-to-react-native-transform、css-to-rn.macro、emotion。另外，你可以参考Tora在样式上的一些规范，以了解这个问题上他们是怎么处理的。

原文来自：https://www.tangshuang.net/7143.html

链接: https://fly63.com/article/detial/9670