CSS-in-JS，向Web組件化再邁一大步

簡介

CSS-in-JS是什麼，看到這個詞就能大概猜到是在JavaScript里寫CSS，那為什麼要在JavaScript里寫CSS呢，像之前一樣寫在css文件里哪裡不好么？

（圖片來自：http://t.cn/R6njCiV）

在介紹這個概念之前，先來回顧一下在日常編寫CSS代碼時都有哪些痛點：

全局污染- CSS的選擇器是全局生效的，所以在class名稱比較簡單時，容易引起全局選擇器衝突，導致樣式互相影響。

命名混亂- 因為怕全局污染，所以日常起class名稱時會盡量加長，這樣不容易重複，但當項目由多人維護時，很容易導致命名風格不統一。

樣式重用困難- 有時雖然知道項目上已有一些相似的樣式，但因為怕互相影響，不敢重用。

代碼冗餘- 由於樣式重用的困難性等問題，導致代碼冗餘。

進化史介紹

在CSS的進化歷史上，出現過各種各樣的框架致力於解決以上的問題：

SASS, LESS- 提供了變數、簡單函數、運算、繼承等，擴展性、重用性都有了很大的提升，解決了一些樣式重用冗餘的問題，但是對於命名混亂問題的效果不大。

BEM (.block__element--modifier)- 比較流行的class命名規則，部分解決了命名混亂和全局污染的問題，但class定義起來還是不太方便，比較冗長，而且和第三方庫的命名還是有可能衝突。

CSS Modules- 模塊化CSS，將CSS文件以模塊的形式引入到JavaScript里，基本上解決了全局污染、命名混亂、樣式重用和冗餘的問題，但CSS有嵌套結構的限制（只能一層），也無法方便的在CSS和JavaScript之間共享變數。

可以看一個簡單的CSS Modules例子了解一下：

生成的dom結構如下圖，基於css文件中的class名稱生成了唯一的class名稱，樣式會定義到生成的class上。

styles列印出來如下圖，定義了css中的class名字和生成的唯一class名字的對應關係。

可以看出，以上框架都解決了不少痛點，但也還是各有一些不足，當然CSS-in-JS也並不是完美的解決了所有問題，我們先來詳細介紹一下。

流行框架介紹

現在隨著組件化概念的流行，對從組件層面維護CSS樣式的需求日益增大，CSS-in-JS就是在組件內部使用JavaScript對CSS進行了抽象，可以對其聲明和加以維護。這樣不僅降低了編寫CSS樣式帶來的風險，也讓開發變得更加輕鬆。它和CSS Modules的區別是不再需要CSS樣式文件。

來看一下幾個流行的CSS-in-JS框架六個月內的下載趨勢：

我們來看看幾個下載量靠前的框架的風格是什麼樣的：

styled-components

先來看看下載量最高的styled-component的代碼風格：

從上圖可以看出，Title和Wrapper都是框架包裝好的component，可以直接在react的jsx語法中使用，在包裝component的時候還定義了標籤分別是h1和section。此段代碼產生的html dom如下圖所示：

可以看到section和h1上分別生成了唯一的class名稱，樣式也對應的定義在生成的class上了。 這樣就可以解決命名混亂和全局污染的問題。組件相關的代碼都在一起，可以統一查看，也可以方便的重用樣式。

glamorous

再來看看glamorous，這個框架是PayPal開發的。（前兩個logo看下來，恍惚間感覺進了化妝品專櫃）。

和styled-component不同的是，glamorous的樣式直接以attribute的形式定義在了dom上，之後雖然也為其生成了class名稱及樣式，但這種以attribute定義的方式對偽類選擇符（如 :hover）支持的不好，會帶來一些不方便，而且需要再記住一套attributes名稱和值與真正的css樣式代碼的對應關係。

JSS

和上面兩個框架類似，jss也是會定義styles對象，並附到component上，最後生成的dom也是會有生成的唯一class名稱，並有對應的樣式，但樣式並不是真正的css語法，而是對象的屬性和值，這樣也是對偽類選擇符支持的不好，而且也需要記住屬性和css樣式代碼之間的對應關係。

Radium

Radium在定義樣式對象上看似和其他相似，但在生成dom結構的時候並沒有生成唯一的class名稱，而是直接把樣式放到了style屬性上，這樣會帶來諸如可讀性差、CSS權重過大、不支持偽類選擇符等問題。

測試

下面再來看一個styled-component提供的基於jest的測試框架：

jest-styled-components

這個框架主要是通過生成Snapshot並比較的方式來保證component樣式的每次更改都會被檢測到，並且樣式是期望的樣式。這樣就又降低了重構CSS樣式帶來的風險。

優劣勢總結

看了這些框架後，可以發現CSS-in-JS的優勢還是挺多的：

因為有了生成的唯一class名稱，避免了全局污染的問題

唯一的class名稱也解決了命名規則混亂的問題

JavaScript和CSS之間可以變數共享，比如一些基礎的顏色和尺寸，這樣再當需要在JavaScript里計算一些高度的時候，可以取到和dom相關的一些padding，margin數值，統一管理

只生成頁面需要用到的代碼，縮減了最終包的大小，提升了性能

CSS的單元測試增加了樣式重構的安全性

但是CSS-in-JS也存在著一些不足和爭議：

有些觀點覺得JS和CSS的關係沒這麼近，把CSS寫進JS里引入了新的一套依賴，增加了複雜度，新人加入項目後需要學習的東西就更多了，也讓學習曲線更加陡了

對前端框架確實有些依賴性，更適合於組件化的框架，如React等

Debug的時候需要花更多的功夫才能找到對應的樣式代碼

覆蓋第三方插件樣式時會有權重不夠的問題

Lint工具對於JavaScript內部的CSS代碼樣式支持的還不夠

最後

在ThoughtWorks最近一期的技術雷達(CSS-in-JS | Technology Radar | ThoughtWorks)里，它的等級是Assess，表示的是：「值得追求。重要的是理解如何建立這種能力。企業應該在風險可控的項目中嘗試此技術。」 所以最後想說的是，雖然它還是有些不足和爭議，在應用之前需要多角度衡量一下對項目的適合度。但它的優點也很多，確確實實解決了很多痛點，而且與web組件化的方向高度一致，希望大家在條件合適的情況下多多嘗試，多多反饋，這樣也能促進整個CSS編碼體驗的繼續進化~

最新期技術雷達將於五月中旬發布，我們將在6月2日舉辦技術雷達峰會（深圳站），與大家共同分享新一期雷達的動向，探討技術趨勢該如何與項目實踐相結合。現在購票，還有限時七折優惠！

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！