CSS架构之 ACSS.png
系列文章
目录
- 前言
- ACSS 的概念
- ACSS 和 CSS-in-JS 为什么会火
- ACSS 优劣
- 如何选择 ACSS 库
- 总结
- 参考
前言
我们知道现在前端开发模式，组件化是比较火的，那么 CSS 开发模式比较火的是什么呢，没错就是我们今天的主角 ACSS，我们先观察下各大型网站的应用：
Twitter 上的 HTML 是这样的：
chrome Twitter
Facebook HTML 是这样的：：
chrome Facebook
最后看看 GitHub 的首页：
等等……
看到 Twitter、Facebook 的类名你可能会吓一跳，但是那也是 ACSS 的一种，相对来讲 GitHub ACSS 更加符合你的直观，无论如何，这么多大公司都用到了 ACSS，说明它确实有效，你应该也要在项目多多尝试尝试。
接下来我们进入 ACSS 的学习。
ACSS 的概念
ACSS 是 Atomic CSS 的简写，它是 Thierry Koblenz 在 2013 年 10 月的文章 Challenging CSS Best Practices 中创造的。
首先，让我们为 原子化 CSS (Atomic CSS) 给出适当的定义：
John Polacek 在文章 Let’s Define Exactly What Atomic CSS is 中写道：
Atomic CSS is the approach to CSS architecture that favors small, single-purpose classes with names based on visual function.
译文：原子化 CSS 是一种 CSS 的架构方式，它倾向于小巧且用途单一的 class，并且会以视觉效果进行命名。
除了叫 ACSS，你还可以称它为函数式 CSS，或者 CSS 实用工具。
CSS 是一个不强调逻辑，而更侧重表现的一门所见即所得的语言，当样式写多了，你就会发现常用样式的来来去去也就那几个，无非就是调整一下他们的排列组合。每次写这些重复的样式代码我就感觉自己是在重复造轮子，自然而然就产生了想要缩写的需求，而 ACSS 做的一些事情很平常，无非就是把 CSS 属性写成一个独立的类名。
.m-0 {
margin: 0;
}
.text-red {
color: red;
}
/* ... */
ACSS 和 CSS-in-JS 为什么会火
前面我们明白了 ACSS 的概念，所以接下来我要讲下 CSS-in-JS 的概念，然后才好解释为什么它们会火。
CSS-in-JS 是很重要的概念，本来打算写篇文章介绍的，题目都取好了 「CSS 架构之 CSS-in-JS」，整理资料发现阮一峰老师写过了，那我就直接拿过来吧 阮一峰——CSS in JS 简介，但是阮老师并没有给出流行 CSS 的解决方案，现在都 21 年了，我们知道目前流行着好几种解决方案，方案各有利弊，我们需要一篇文章来通透的理解它们，于是 @FateRiddle 同学的 React拾遗：从10种现在流行的 CSS 解决方案谈谈我的最爱 （上） 这篇文章出现了。
你可以先不看上面的文章链接，我来给你梳理下：
很久以前，前端项目比较小，HTML、CSS、JS 都耦合在一起，后来随着项目越来越大，为了便于维护，代码不允许在耦合，要求各个技术只负责自己的领域。
在后来，伴随着 React 出现，前端组织代码的方式变了，组件成为组织代码主流方法，而组件的核心原则就是代码完全不依赖外部，表现在 React 中就是 HTML、CSS、JS 强强耦合，这样就避免了影响其他组件，对于 CSS 我们也写在了 JS 中，这就要 CSS in JS，其实就是写行内样式。
但行内样式不支持伪类、媒体查询，于是出现了 React-JSS 这种库，对行内样式进行扩展；有人又不能忍受 React-JSS 这种样式驼峰的写法；出现了 styled-components，遵循 CSS 写法规范的库；有人比较喜欢不耦合的写法，于是 Css Module 出现了；还有人觉得 Vue 的解决办法比较优雅，然后就出现了 styled-jsx。
我来总结下：
CSS-in-JS 本质就是行内样式，之所以会火就是因为组件化时代的到来。
看明白 CSS in JS 火的原理，你肯定猜到 ACSS 会火的原因——那就是组件化时代的到来，你甚至可以理解为 ACSS 就是 CSS 架构下得 CSS 组件化。
在没有组件化的传统网页开发时代，如果你通过 ACSS 来确定样式，例如下面代码的形式，合作的小伙伴肯定以为你疯了：
<button class="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded">按钮</button>
因为 button 的复用率很高，你项目到处充斥着这种 button，一旦 button 要修改某些样式，你可去哭娘去吧，这哪有直接给个 .btn 类名方便，要修改直接改类名就行了，例如下面：
<button class="btn">按钮</button>
但是在组件化时代就不一样了，例如使用 React 封装一个 Button：
const Button = ({ children, color }) => (
<button class=`bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded ${color}`>{children}</button>
)
使用如下：
<Button color="pink"> 注册 </Button>
如果样式有修改，我只要插拔 ACSS 就行了，而且对比使用 .btn 实现，样式的重用性会极大提高，理解也很容易。
这下你明白了吗，要说 ACSS 和 CSS-in-JS 为什么会火，就是因为组件化。
ACSS 优劣
使用 ACSS 的好处：
- 你的 CSS 停止增长。使用传统方法，每次添加新功能时，您的 CSS 文件都会变大。使用实用程序，一切都是可重用的，因此您很少需要编写新的 CSS，一套样式全局通用。
-
你不是在浪费精力发明类名。不再添加愚蠢的类名，例如
sidebar-inner-wrapper只是为了能够设置样式，也不再为真正只是一个 flex 容器的东西的完美抽象名称而苦恼。 - 灵活，易读。CSS 是全球性的，当你做出改变时，你永远不知道你破坏了什么。HTML 中的类是本地的，因此您可以 插拔式改变样式 而不必担心其他问题，CSS 样式很多缩写更加符合大脑的记忆。
- 永远不用担心命名冲突，永远不用担心样式覆盖。
使用 ACSS 劣处：
- 毫无疑问，ACSS 会增加HTML 的体积，但是借助 Gzip 这个就不是大问题。
- 熟悉命名 ACSS 命名会有一定成本。
ACSS 劣处是非常小的，而好处有非常大，没有理由在项目中不适用，强烈建议你每个前端项目都是用 ACSS。
如何选择 ACSS 库
市面上有不少成熟的 CSS 框架，如 Tailwind CSS，Windi CSS 以及 Tachyons 等。
同时有些 UI 库也会附带一些 CSS 工具类作为框架的补充，如 Bootstrap 和 Chakra UI。
甚至还有一些人根据项目总结出来自己的 ACSS，例如 atom.css、SACSS: Static Atomic CSS 等。
ACSS 库大致就分为这三类了。
把它们整合到我们的项目，那我们选择的标准是什么呢？
-
按需生成，比如我们使用
class="m-1"来设置 margin，那么 m-x，x 到底是多大呢，x 但不管 x 是多大，当增加 x 的时候，margin 不同方向，比如mt代表margin-top，mb代表margin-bottom等，也得增加，如果加上:hover和:focus这样的伪类时，体积还会得更变大，原子类太多了，应该提供按需生成只加载我们用过的。 -
动态化，原子类不应该是完全静态化的，比如我要使用
class="m-100"，我应该可以是直接使用，而不是设置完之后，发现样式没生效，然后通过框架的配置文件，去增加对 m-100 的支持，原子类要把可插拔做到极致。
除了上面两个是非常重要的标准，我认为 自动值推导 和 属性化模式 也是提升了开发体验要考虑的部分。
我们来看看我们最终会选择哪个 ACSS 库，首先原子 CSS 一定要纯净，所以 UI 框架附带的 ACSS 就不能采用了，根据项目总结的 ACSS，它的原子 CSS 太过静态，不能随想随用，不符合原子类不应该是完全静态化的标准，Tailwind CSS 本来是没有按需生成的，后来增加了，但是 Windi CSS 速度更快还兼容 Tailwind CSS，所以我们很自然就必须必的选择了 Windi CSS 。
总结
我们先通过举例子，了解了 ACSS 的使用，然后介绍了 ACSS 的概念，通过对比 CSS-in-JS 来剖析 ACSS 借助前端组件化浪潮开始起飞的过程，最后如何在项目中选择自己的 ACSS 库，我们通过一些硬性标准，分析了三类 ACSS 库，帮你选择了 Windi CSS 。
网友评论