Facebook 重構(gòu):拋棄 Sass / Less ,迎接原子化 CSS 時代
隨著 Facebook 和 Twitter 最近的產(chǎn)品部署,我認為一個新的趨勢正在緩慢增長:Atomic CSS-in-JS。
在這篇文章中,我們將看到什么是Atomic CSS(原子 CSS),它如何與 Tailwind CSS 這種實用工具優(yōu)先的樣式庫聯(lián)系起來,目前很多大公司在 React 代碼倉庫中使用它們。
由于我不是這方面的專家,所以我不會去深入探討它的利弊。我只是希望能幫助你了解它的大致內(nèi)容。
先拋出一個令人開心的結(jié)論,新的 CSS 編寫和構(gòu)建方式讓 Facebook 的主頁減少了 80% 的 CSS 體積。
什么是原子 CSS?
你可能聽說過各種 CSS 方法,如 BEM, OOCSS…
- <button class="button button--state-danger">Danger button</button>
現(xiàn)在,人們真的很喜歡 Tailwind CSS[1] 和它的 實用工具優(yōu)先(utility-first)[2] 的概念。這與 Functional CSS 和 Tachyon[3] 這個庫的理念非常接近。
- <button
- class="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded"
- >
- Button
- </button>
用海量的實用工具類(utility classes)組成的樣式表,讓我們可以在網(wǎng)頁里大顯身手。
原子 CSS 就像是實用工具優(yōu)先(utility-first)CSS 的一個極端版本: 所有 CSS 類都有一個唯一的 CSS 規(guī)則。原子 CSS 最初是由 Thierry Koblentz (Yahoo!)在 2013 年挑戰(zhàn) CSS 最佳實踐[4]時使用的。
- /* 原子 CSS */
- .bw-2x {
- border-width: 2px;
- }
- .bss {
- border-style: solid;
- }
- .sans {
- font-style: sans-serif;
- }
- .p-1x {
- padding: 10px;
- }
- /* 不是原子 CSS 因為這個類包含了兩個規(guī)則 */
- .p-1x-sans {
- padding: 10px;
- font-style: sans-serif;
- }
使用實用工具/原子 CSS,我們可以把結(jié)構(gòu)層和表示層結(jié)合起來:當我們需要改變按鈕顏色時,我們直接修改 HTML,而不是 CSS!
這種緊密耦合在現(xiàn)代 CSS-in-JS 的 React 代碼庫中也得到了承認,但似乎 是 CSS 世界里最先對傳統(tǒng)的關(guān)注點分離有一些異議。
CSS 權(quán)重也不是什么問題,因為我們使用的是最簡單的類選擇器。
我們現(xiàn)在通過 html 標簽來添加樣式,發(fā)現(xiàn)了一些有趣的事兒:
我們增加新功能的時候,樣式表的增長減緩了。
我們可以到處移動 html 標簽,并且能確保樣式也同樣生效。
我們可以刪除新特性,并且確保樣式也同時被刪掉了。
可以肯定的缺點是,html 有點臃腫。對于服務器渲染的 web 應用程序來說可能是個缺點,但是類名中的高冗余使得 gzip 可以壓縮得很好。同時它可以很好地處理之前重復的 css 規(guī)則。
一旦你的實用工具/原子 CSS 準備好了,它將不會有太大的變化或增長??梢愿行У鼐彺嫠?你可以將它附加到 vendor.css 中,重新部署的時候它也不會失效)。它還具有相當好的可移植性,可以在任意其他應用程序中使用。
實用工具/原子 CSS 的限制
實用工具/原子 CSS 看起來很有趣,但它們也帶來了一些挑戰(zhàn)。
人們通常手工編寫實用工具/原子 CSS,精心制定命名約定。但是很難保證這個約定易于使用、保持一致性,而且不會隨著時間的推移而變得臃腫。
這個 CSS 可以團隊協(xié)作開發(fā)并保持一致性嗎?它受巴士因子[5]的影響嗎?
巴士系數(shù)是軟件開發(fā)中關(guān)于軟件專案成員之間訊息與能力集中、未被共享的衡量指標,也有些人稱作“貨車因子”、“卡車因子”(lottery factor/truck factor)。一個專案或計劃至少失去若干關(guān)鍵成員的參與(“被巴士撞了”,指代職業(yè)和生活方式變動、婚育、意外傷亡等任意導致缺席的緣由)即導致專案陷入混亂、癱瘓而無法存續(xù)時,這些成員的數(shù)量即為巴士系數(shù)。
你還需要預先開發(fā)好一個不錯的實用工具/原子樣式表,然后才能開始開發(fā)新功能。
如果實用工具/原子 CSS 是由別人制作的,你將不得不首先學習類命名約定(即使你知道 CSS 的一切)。這種約定是有主觀性的,很可能你不喜歡它。
有時,你需要一些額外的 CSS,而實用工具/原子 CSS 并不提供這些 CSS。沒有約定好的方法來提供這些一次性樣式。
Tailwind 趕來支援
Tailwind 使用的方法是非常便捷的,并且解決了上述一些問題。
它通過 Utility-First 的理念來解決 CSS 的一些缺點,通過抽象出一組類名 -> 原子功能的集合,來避免你為每個 div 都寫一個專有的 class,然后整個網(wǎng)站重復寫很多重復的樣式。
傳統(tǒng)卡片樣式寫法:
Tailwind 卡片樣式寫法:
它并不是真的為所有網(wǎng)站提供一些唯一的實用工具 CSS,取而代之的是,它提供了一些公用的命名約定。通過一個配置文件[6],你可以為你的網(wǎng)站生成一套專屬的實用工具 CSS。
ssh 注:這里原作者沒有深入介紹,為什么說是一套命名約定呢而不是生成一些定死的 CSS 呢?
舉幾個例子讓大家感受一些,Tailwind 提供了一套強大的構(gòu)建系統(tǒng),比如默認情況下它提供了一些響應式的斷點值:
- // tailwind.config.js
- module.exports = {
- theme: {
- screens: {
- 'sm': '640px',
- // => @media (min-width: 640px) { ... }
- 'md': '768px',
- // => @media (min-width: 768px) { ... }
- 'lg': '1024px',
- // => @media (min-width: 1024px) { ... }
- 'xl': '1280px',
- // => @media (min-width: 1280px) { ... }
- }
- }
- }
你可以隨時在配置文件中更改這些斷點,比如你所需要的小屏幕 sm 可能指的是更小的 320px,那么你想要在小屏幕時候采用 flex 布局,還是照常寫 sm:flex,遵循同樣的約定,只是這個 sm 已經(jīng)被你修改成適合于項目需求的值了。
在比如說,Tailwind 里的 spacing 掌管了 margin、padding、width 等各個屬性里的代表空間占用的值,默認是采用了 rem 單位,當你在配置里這樣覆寫后:
- // tailwind.config.js
- module.exports = {
- theme: {
- spacing: {
- '1': '8px',
- '2': '12px',
- '3': '16px',
- '4': '24px',
- '5': '32px',
- '6': '48px',
- }
- }
- }
你再去寫 h-6(height), m-2(margin), mb-4(margin-bottom),后面數(shù)字的意義就被你改變了。
也許從桌面端換到移動端項目,這個 6 代表的含義變成了 6rem,但是這套約定卻深深的印在你的腦海里,成為你知識的一部分了。
Tailwind 的知識可以遷移到其他應用程序,即使它們使用的類名并不完全相同。這讓我想起了 React 的「一次學習,到處編寫」理念。
我看到一些用戶反饋說,Tailwind 提供的類名能覆蓋他們 90% - 95% 的需求。這個覆蓋面似乎已經(jīng)足夠廣了,并不需要經(jīng)常寫一次性的 CSS 了。
此時,你可能想知道為什么要使用原子 CSS 而不是 Tailwind CSS?強制執(zhí)行原子 CSS 規(guī)則的一個規(guī)則,一個類名,有什么好處?你最終會得到更大的 html 標簽和更煩人的命名約定嗎?Tailwind 已經(jīng)有了足夠多的原子類了啊。
那么,我們是否應該放棄原子 CSS 的想法,而僅僅使用 Tailwind CSS?
Tailwind 是一個優(yōu)秀的解決方案,但仍然有一些問題沒有解決:
- 需要學習一套主觀的命名約定
- CSS 規(guī)則插入順序仍然很重要
- 未使用的規(guī)則可以輕松刪除嗎?
- 我們?nèi)绾翁幚硎O碌囊淮涡詷邮?
與 Tailwind 相比,手寫原子 CSS 可能不是最方便的。
和 CSS-in-JS 比較
CSS-in-JS 和實用工具/原子 CSS 有密切關(guān)系。這兩種方法都提倡使用標簽進行樣式化。以某種方式試圖模仿內(nèi)聯(lián)樣式,這讓它們有了很多相似的特性(比如在移動某些功能的時候更有信心)。
Christopher Chedeau[7] 一直致力于推廣 React 生態(tài)系統(tǒng)中 CSS-in-JS 理念。在很多次演講中,他都解釋了 CSS 的問題:
- 全局命名空間
- 依賴
- 無用代碼消除
- 代碼壓縮
- 共享常量
- 非確定性(Non-Deterministic)解析
- 隔離
實用工具/原子 CSS 也解決了其中的一些問題,但也確實沒法解決所有問題(特別是樣式的非確定性解析)。
如果它們有很多相似之處,那我們能否同時使用它們呢?
探索原子 CSS-in-JS
原子 CSS-in-JS 可以被視為是“自動化的原子 CSS”:
- 你不再需要創(chuàng)建一個 class 類名約定
- 通用樣式和一次性樣式的處理方式是一樣的
- 能夠提取頁面所需要的的關(guān)鍵 CSS,并進行代碼拆分
- 有機會修復 JS 中 CSS 規(guī)則插入順序的問題
我想強調(diào)兩個特定的解決方案,它們最近推動了兩個大規(guī)模的原子 CSS-in-JS 的部署使用,來源于以下兩個演講。
- React-Native-Web at Twitter (更多細節(jié)在Nicolas Gallagher 的演講[8])。
- Stylex at Facebook (更多細節(jié)在Frank Yan 的演講[9])。
也可以看看這些庫:
- Styletron
- Fela
- Style-Sheet
- cxs
- otion
- css-zero
- ui-box
- style9
- stitches
- catom
React-Native-Web
React-Native-Web 是一個非常有趣的庫,讓瀏覽器也可以渲染 React-Native 原語。不過我們這里并不討論跨平臺開發(fā)(演講里有更多細節(jié))。
作為 web 開發(fā)人員,你只需要理解 React-Native-Web 是一個常規(guī)的 CSS-in-JS 庫,它自帶一些原始的 React 組件。所有你寫 View 組件的地方,都可以用 div 替換。
React-Native-Web 的作者是 Nicolas Gallagher,他致力于開發(fā) Twitter 移動版。他們逐漸把它部署到移動設備上,不太確定具體時間,大概在 2017/2018 年左右。
從那以后,很多公司都在用它(美國職業(yè)足球大聯(lián)盟、Flipkart、Uber、紐約時報……),但最重要的一次部署,則是由 Paul Armstrong 領(lǐng)導的團隊在 2019 年推出的新的 Twitter 桌面應用。
Stylex
Stylex 是一個新的 CSS-in-JS 庫,F(xiàn)acebook 團隊為了 2020 年的 Facebook 應用重構(gòu)而開發(fā)它。未來可能會開源,有可能用另一個名字。
值得一提的是,React-Native-Web 的作者 Nicolas Gallagher 被 Facebook 招安。所以里面出現(xiàn)一些熟悉的概念一點也不奇怪。
我的所有信息都來自演講 :),還需要等待更多的細節(jié)。
可擴展性
不出所料,在 Atomic CSS 的加成下,Twitter 和 Facebook 的 CSS體積都大幅減少了,現(xiàn)在它的增長遵循的是對數(shù)曲線。不過,簡單的應用則會多了一些 初始體積
Facebook 分享了具體數(shù)字:
源碼和輸出
這兩個庫的 API 看起來很相似,但也很難說,因為我們對 Stylex 了解不多。
值得強調(diào)的是,React-Native-Web 會擴展 CSS 語法糖,比如 margin: 0,會被輸出為 4 個方向的 margin 原子規(guī)則。
以一個組件為例,來看看舊版?zhèn)鹘y(tǒng) CSS 和新版原子 CSS 輸出的區(qū)別。
- <Component1 classNames="class1" /> <Component2 classNames="class2" />
- .class1 {
- background-color: mediumseagreen;
- cursor: default;
- margin-left: 0px;
- }
- .class2 {
- background-color: thistle;
- cursor: default;
- jusify-content: flex-start;
- margin-left: 0px;
- }
可以看出這兩個樣式中 cursor 和 margin-left 是一模一樣的,但它在輸出中都會占體積。
再來看看原子 CSS 的輸出:
- <Component1 classNames="classA classC classD" />
- <Component2 classNames="classA classB classD classE" />
- class a {
- cursor: default;
- }
- class b {
- background-color: mediumseagreen;
- }
- class C {
- background-color: thistle;
- }
- class D {
- margin-left: 0px;
- }
- class E {
- jusify-content: flex-start;
- }
可以看出,雖然標簽上的類名變多了,但是 CSS 的輸出體積會隨著功能的增多而減緩增長,因為出現(xiàn)過一次的 CSS Rule 就不會再重復出現(xiàn)了。
生產(chǎn)環(huán)境驗證
我們看看 Twitter 上的標簽是什么樣子的:
現(xiàn)在,讓我們來看看新 Facebook:
很多人可能會被嚇到,但是其實它很好用,而且保持了 可訪問性[10]。
在 Chrome 里檢查樣式可能有點難,但 devtools 里就看得很清楚了:
CSS 規(guī)則順序
與手寫的工具/原子 CSS 不同,JS 庫能讓樣式不依賴于 CSS 規(guī)則的插入順序。
在規(guī)則沖突的情況下,生效的不是標簽上 class attribute 中的最后一個類,而是樣式表中最后插入的規(guī)則。
以這張圖為例,我們期望的是書寫在后的 blue 類覆蓋前面的類,但實際上 CSS 會以樣式表中的順序來決定優(yōu)先級,最后我們看到的是紅色的文字。
在實際場景中,這些庫避免在同一個元素上寫入多個規(guī)則沖突的類。它們會確保標簽上書寫在最后的類名生效。其他的被覆蓋的類名則被規(guī)律掉,甚至壓根不會出現(xiàn)在 DOM 上。
- const styles = pseudoLib.create({
- red: {color: "red"},
- blue: {color: "blue"},
- });
- // 只會輸出 blue 相關(guān)的 CSS
- <div style={[styles.red, styles.blue]}>
- Always blue!
- </div>
- // 只會輸出 red 相關(guān)的 CSS
- <div style={[styles.blue, styles.red]}>
- Always red!
- </div>
注意:只有使用最嚴格的原子 CSS 庫才能實現(xiàn)這種可預測的行為。
如果一個類里有多個 CSS 規(guī)則,并且只有其中的一個 CSS 規(guī)則被覆蓋,那么 CSS-in-JS 庫沒辦法進行相關(guān)的過濾,這也是原子 CSS 的優(yōu)勢之一。
如果一個類只有一個簡單的 CSS 規(guī)則,如 margin: 0,而覆蓋的是 marginTop: 10。像 margin: 0 這樣的簡寫語法被擴展為 4 個不同的原子類,這個庫就能更加輕松的過濾掉不該出現(xiàn)在 DOM 上的類名。
仍然喜歡 Tailwind?
只要你熟悉所有的 Tailwind 命名約定,你就可以很高效的完成 UI 編寫。一旦你熟悉了這個設定,就很難回到手寫每個 CSS 規(guī)則的時代了,就像你寫 CSS-in-JS 那樣。
沒什么能阻止你在原子 CSS-in-JS 的框架上建立你自己的抽象 CSS 規(guī)則,Styled-system[11]就能在 CSS-in-JS 庫里完成一些類似的事情。它基于一些約定創(chuàng)造出一些原子規(guī)則,在 emotion 中使用它試試:
- import styled from '@emotion/styled';
- import { typography, space, color } from 'styled-system';
- const Box = styled('div')(typography, space, color);
等效于:
- <Box
- fontSize={4}
- fontWeight="bold"
- p={3}
- mb={[4, 5]}
- color="white"
- bg="primary"
- >
- Hello
- </Box>
甚至有可能在 JS 里復用一些 Tailwind 的命名約定,如果你喜歡的話。
先看些 Tailwind 的代碼:
- <div className="absolute inset-0 p-4 bg-blue-500" />
我們在谷歌上隨便找一個方案,比如我剛剛發(fā)現(xiàn) react-native-web-tailwindcss[12]:
- import { t } from 'react-native-tailwindcss';
- <View style={[t.absolute, t.inset0, t.p4, t.bgBlue500]} />;
就生產(chǎn)力的角度而言,并沒有太大的不同。甚至可以用 TS 來避免錯別字。
結(jié)論
這就是我要說的關(guān)于原子 CSS-in-JS 所有內(nèi)容。
我從來沒有在任何大型生產(chǎn)部署中使用過原子 CSS、原子 CSS-in-JS 或 Tailwind。我可能在某些方面是錯的,請隨時糾正我。
我覺得在 React 生態(tài)系統(tǒng)中,原子 CSS-in-JS 是一個非常值得關(guān)注的趨勢,我希望你能從這篇文章中學到一些有用的東西。
感謝閱讀。
參考資料
[1]Tailwind CSS: https://tailwindcss.com/
[2]實用工具優(yōu)先(utility-first): https://tailwindcss.com/docs/utility-first
[3]Tachyon: https://github.com/tachyons-css/tachyons
[4]挑戰(zhàn) CSS 最佳實踐: https://www.smashingmagazine.com/2013/10/challenging-css-best-practices-atomic-approach/
[5]巴士因子: https://zh.wikipedia.org/wiki/%E5%B7%B4%E5%A3%AB%E5%9B%A0%E5%AD%90
[6]配置文件: https://tailwindcss.com/docs/configuration
[7]Christopher Chedeau: https://twitter.com/vjeux
[8]Nicolas Gallagher 的演講: https://www.youtube.com/watch?v=tFFn39lLO-U
[9]Frank Yan 的演講: https://www.youtube.com/watch?v=9JZHodNR184
[10]可訪問性: https://github.com/necolas/react-native-web/blob/master/packages/docs/src/guides/accessibility.stories.mdx
[11]Styled-system: https://styled-system.com/
[12]react-native-web-tailwindcss: https://www.npmjs.com/package/react-native-web-tailwindcss
本文轉(zhuǎn)載自微信公眾號「前端從進階到入院」,可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系前端從進階到入院公眾號。