深入解析一下CSS架構之ACSS

這篇文章為大家帶來了關於css架構ACSS的相關知識，其中詳細介紹了ACSS的概念、優勢以及怎樣選擇ACSS庫，希望對大家有幫助。

前言

#我們知道現在前端開發模式，元件化是比較火的，那麼CSS開發模式比較火紅的是什麼呢，沒錯就是我們今天的主角ACSS，我們先觀察下各大型網站的應用：

Twitter 上的HTML 是這樣的：

Facebook HTML 是這樣的：：

最後看看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 优劣

使用 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 

（学习视频分享：css视频教程）

以上是深入解析一下CSS架構之ACSS的詳細內容。更多資訊請關注PHP中文網其他相關文章！