聊聊原子类（Atomic CSS）

借着 Tailwind CSS 的热度，这几年原子类再次走入前端视野。我对它多有耳闻，但一直不理解为什么会火——这和写 inline style 能有多大区别呢？

这两天和同事聊到原子类，突然脑袋灯泡一亮，理解了它的价值所在。在此权作记录。

什么是原子类

通常我们写 CSS，都是在一个类里写一系列 property，例如：

<style>
  .card {
    padding: 20px;
    font-size: 14px;
    color: #000000;
  }
</style>

<div class="card"></div>

而所谓原子类，就是把每一句 property 都拆成一个 CSS 类，让它们像「原子」一样，通过类的组合，拼接成最终的样式。

用原子类改写上面的样式：

<style>
  .p-20 {
    padding: 20px;
  }
  .fs-md {
    font-size: 14px;
  }
  .fc-black {
    color: #000000;
  }
</style>

<div class="p-20 fs-md fc-black"></div>

容易发现，这种写法和古早的 inline style 很相似：

<div style="padding: 20px; font-size: 14px; color: #000000;"></div>

这是 inline style 的复辟吗？原子类是不是多此一举？

为什么不用 inline style

权重

CSS 选择器权重是最明显的优势。

inline style 权重高到离谱，以至于几乎没法覆写（ (1, 0, 0, 0) ），而 class 仅为 (0, 0, 1, 0)。

同时，由于原子类通常写法是平铺，这避免了选择器嵌套，使得覆盖样式时几乎无需考虑权重问题：

<!-- 传统写法 -->
<style>
  .parent .child {
    color: red; /* 该样式选择器权重为 (0, 0, 2, 0)，最少要写两个 class 才能覆盖得了 */
  }
</style>

<div class="parent">
  <div class="child"></div>
</div>

<!-- 原子类写法 -->
<style>
  .fc-red {
    color: red; /* 该样式选择器权重为 (0, 0, 1, 0)，只需一个 class 就能覆盖 */
  }
</style>

<div>
  <div class="fc-red"></div>
</div>

实现 inline style 做不到的样式

举例：

.hover-red {
  &:hover {
    color: red;
  }
}

规范设计系统，减少输入负担

原子类应当是配合设计系统使用的。由于它限定了样式的数量，前端样式不会有太多自定义内容，从而被强制规范化。同时前端与 UI 设计系统的一致，也使得「通过转换工具，将样式直接从设计稿套用到代码」成为可能。

原子类的简短名称，避免了每次都要输入冗长的 style 语句，更短的输入内容也能减少输错字符的情况。

为什么不用常规 class

不再重要的「可复用性」

inline style 之所以成为「最差实践」，一是样式权重高，二是可复用性差。推荐使用 class 的一个原因也是它的高复用性。但现代 Web 开发中，class 的复用性是否依然重要？

现在复用的基本单位已是整个组件：当另一处用到相同内容时，不再是编写 HTML + 复用 CSS，而是将整个组件 import 过去。

在一个组件内部能有多少复用的样式呢？

能复用的，多半是些全局都可能用到的样式。例如 ".ellipsis"、".primary-color"——这种一般可以称做「样式规范」，也正是原子类所包含的内容，使用原子类等于已经带上了这些场景中的复用性。

减小打包体积

常规 class 中不可避免会有重复的 property，以致存在冗余。更换为原子类能减少此类冗余，对于不冗余的内容也能减少字符数量，总体上减小打包体积。

搭建设计系统的必经之路

由于公司项目设计系统不规范，我设想过用一整套工具链，在前端和 UI 之间统一与规范设计系统：

设计部门搭建设计系统，通过 lint 规范设计稿必须遵循系统
自动化工具，将设计系统导出生成 NPM 包
前端项目中引入 NPM 包，此时可在 CSS 中引用设计系统的样式
为了方便引用设计系统，它的样式用 "pd-lg" "font-sm" 之类的代号表示
- 设计稿中包含代号信息，方便开发人员引用
- 在 CSS 中可混写 property 和代号，代号使用特定前缀区分。通过 Babel 等将样式代号转换为实际样式。例如：
```
.card {
  margin: 10px 0;
  /pd-lg; /* 代号 */
  /font-sm; /* 代号 */
  color: #000000;
}
```
编写 VSCode 插件，功能：代号说明、代号自动补全、lint 错误代号、将现有 CSS property 转为代号
设计系统有变化，更新 NPM 包；前端 NPM 包升级后，相关样式自动统一改变

接着我发现，前端 CSS 混写的思路，和这个 Babel macro 很像；

进一步我发现，其实我就是在做一个原子类。

为什么不用 CSS-in-JS

上手简单

相比需要配置 Webpack loader、Babel plugin 的 CSS-in-JS 方案，理想的原子类只需在全局引入一个 .css 文件就能立即使用。

这里要提一下 Tailwind CSS，它由于本身复杂性，以及带有 hack，所以需要做一定配置。如果是稍简单一点的原子类方案，不需要这么做。

易于迁移

除 CSS Modules 外，大部分 CSS-in-JS 方案和框架强绑定。例如使用 styled-components 的 React 项目，改造成 Vue 需要大量改写样式。原子类由于本身仅仅是 class，在各框架中都支持，能无缝迁移。

原子类的问题

正所谓「没有银弹」，原子类只是解决上述问题比较普适的一个方案。经历过潮流的一次轮回，它仍未完全替代传统 class，正是因为其本身存在的一些问题。

有一定学习成本

原子类本身有一定的学习成本，虽然有相关插件能减少认知负担，使用时还是要大量查阅文档。

不能完全取代 class

class 除了提供样式，也具有「语义化」的功能。一个清晰的 class，能告诉读者这个 HTML 元素起到什么作用。

它还作为 HTML 元素的标记：传统 Web 开发常常使用 querySelector(className) 来获取 DOM 元素。如果仅使用原子类，就只能用 id 获取元素，或者迁移到现代 Web 框架。

Tailwind CSS 作者也指出，「该用传统 class 时就用 class」。

无法实现一些复杂效果

这些场景其实在开发中是很常见的：

/* 特殊伪元素 */
.list-item::before {
  content: counter(name);
}

/* 特殊伪类 */
.item:nth-child(n + 1) {
  color: red;
}
.item:nth-child(n + 2) {
  color: green;
}
.item:nth-child(n + 3) {
  color: blue;
}

/* 自定义动画 */
@keyframe boom {
  0% {
    transform: scale(1);
  }
  50% {
    transform: scale(3);
  }
  100% {
    transform: scale(0);
  }
}

对于此类特殊场景，常规原子类无法满足，仍须为其编写专用 class

我为什么不用原子类

原子类就聊到这里。

你可能会问，我在用原子类吗？我的回答是「没有」。原因有三：

无法实现复杂效果
公司的项目没有完善的设计系统
自己的项目懒得搞设计系统

以上。