簡介
因為技術站的更新，我們公司 M 站的專案，開始往 React 遷移。然後在對於 React 中 CSS 的使用方式上，我和一個同事有了很大的分歧。
我是一個非常推崇原子化使用 CSS 的人。我喜歡使用類似：
.dn{ display:block; }
.fs24{ font-size:24px; }
.pr{ position:relative; }
/*...*/複製程式碼這樣的方式去使用 CSS 樣式。和我角度不一樣的同事可能會更傾向於元件化的方式，類似：
.demo{
position:relative;
display:block;
font-size:24px;
/*...*/
}複製程式碼我第一次對於原子化這種 CSS 的方式有了解，是來自我的男神，張鑫旭的活字印刷CSS。後面在和同事爭論的時候，又查閱了很多的資料。發現可能用得最久也是一直在堅持做的，可能是來自雅虎的「Atomic CSS」。他們在使用方式上有很大的差別，但是他們的原子化 CSS 的思維是一樣的。
示例
這篇文章其實我主要是想通過一個例子（我真的是用盡了洪荒之力才想出來的），來讓大家理解元件化和原子化的區別。
假設我們有名為「原子」和「元件」兩個機器人制造廠。
他們現在要同時競標一個製造3種機器人各50臺的專案。這3個機器人長這樣「 原諒我拙略的繪畫技巧 」：
然後兩個廠回去之後給到了如下的方案：
第一眼我們看過去，我們肯定會覺得「元件廠」的整個設計乾淨整潔，然後「原子廠」這個亂七八糟的是個什麼鬼？
然後我們再來看看他們的模具需求是什麼樣的：
在「元件廠」裡因為3個機器人的手是一樣的，所以他們並不需要做15（3*5）個元件，而只需要做10個元件就好。
對於 「原子廠」來說他們把元件拆分到了最小的單位，所以只需要9個元件。
然後如果我們臨時需要再新增兩種機器人：
「元件廠」這邊因為有3個元件之前已經有了，所以這邊需要再增加6個元件。
「原子廠」這邊因為沒有橙色，所以這邊需要再增加一個橙色的原子元件。
我這幾個圖裡面，其實忽略了元件到整體的這個拼裝成本。對於「元件廠」來說，元件到整體每個機器人需要拼接4次，而「原子廠」則需要拼接：14次（5*2+4）次。
大家如果把這個機器人，想象成我們網頁中的模組，這中間的顏色和形狀想象成我們的CSS屬性，就能理解在我們 CSS 的世界裡面，元件化和原子化是什麼樣的一種狀況了。
在 @FateRiddle 同學的文章 React拾遺：從10種現在流行的 CSS 解決方案談談我的最愛 （中）有提到，原子化的概念，是inline css一中簡寫方式，在元件化開發浪潮中才真正變得可行。
當然我講這個的目的不是要證明原子化的思維比元件化的思維更好。因為就我個人而言，我覺得「原子化」其實只是「元件化」的一種極致使用方式而已。在React CSS的寫法裡面，應該是一個可以值得嘗試的方案。
這裡還有一篇從思維方式，到專案經驗，到和網友鬥嘴等各個方面介紹「Rethinking CSS」的網頁，強烈推薦大家看一下。
解決方案
更新於 2019/10/22
| 名稱 | NPM | github | CDN |
|---|---|---|---|
@_nu/css-acss |
 |
 |
講了這麼多，感覺都只是空談理論。這邊我多年的使用經驗，總結的一個 ACSS 的 npm 類庫 @_nu/css-acss 供大家使用。
對於 ACSS, bootstrap, material-ui, github ... 都有相關的 類庫，然後整個 ** 類庫** 最完善的屬於 tailwindcss。當然他們都是基於 style-system 理論建立的。上手成本相對較高，且往往需要設計師的介入。
和這些專案相比，我這邊的方案，優點在於簡單和極致的 CSS 開發體驗。簡單到整個邏輯只落點在命名規則，看完文件 5 分鐘就會用，甚至完全理解所有的邏輯。極致的 CSS 開發體驗，體現在熟悉這套規則之後，你會開始懷疑，你的手指速度慢於你思考 CSS 的速度。
當然為了追求簡單和開發體驗這也是缺點，就是不夠完善，沒有處理類似 hover,focus... 等中間態，也沒有新增任何自定義的響應點。這部分需要大家基於自己專案和 命名規則 自由擴充套件。