簡介
CSS-in-JS是什么，看到這個詞就能大概猜到是在JavaScript里寫CSS，那為什么要在JavaScript里寫CSS呢，像之前一樣寫在css文件里哪里不好么？
在介紹這個概念之前，先來回顧一下在日常編寫CSS代碼時都有哪些痛點：
- 全局污染 - CSS的選擇器是全局生效的，所以在class名稱比較簡單時，容易引起全局選擇器沖突，導致樣式互相影響。
- 命名混亂 - 因為怕全局污染，所以日常起class名稱時會盡量加長，這樣不容易重復，但當項目由多人維護時，很容易導致命名風格不統(tǒng)一。
- 樣式重用困難 - 有時雖然知道項目上已有一些相似的樣式，但因為怕互相影響，不敢重用。
- 代碼冗余 - 由于樣式重用的困難性等問題，導致代碼冗余。
進化史介紹
在CSS的進化歷史上，出現(xiàn)過各種各樣的框架致力于解決以上的問題：
- SASS, LESS - 提供了變量、簡單函數(shù)、運算、繼承等，擴展性、重用性都有了很大的提升，解決了一些樣式重用冗余的問題，但是對于命名混亂問題的效果不大。
- BEM (.block__element--modifier) - 比較流行的class命名規(guī)則，部分解決了命名混亂和全局污染的問題，但class定義起來還是不太方便，比較冗長，而且和第三方庫的命名還是有可能沖突。
- CSS Modules - 模塊化CSS，將CSS文件以模塊的形式引入到JavaScript里，基本上解決了全局污染、命名混亂、樣式重用和冗余的問題，但CSS有嵌套結(jié)構(gòu)的限制（只能一層），也無法方便的在CSS和JavaScript之間共享變量。
可以看一個簡單的CSS Modules例子了解一下：
生成的dom結(jié)構(gòu)如下圖，基于css文件中的class名稱生成了唯一的class名稱，樣式會定義到生成的class上。
styles打印出來如下圖，定義了css中的class名字和生成的唯一class名字的對應關(guān)系。
可以看出，以上框架都解決了不少痛點，但也還是各有一些不足，當然CSS-in-JS也并不是完美的解決了所有問題，我們先來詳細介紹一下。
流行框架介紹
現(xiàn)在隨著組件化概念的流行，對從組件層面維護CSS樣式的需求日益增大，CSS-in-JS就是在組件內(nèi)部使用JavaScript對CSS進行了抽象，可以對其聲明和加以維護。這樣不僅降低了編寫CSS樣式帶來的風險，也讓開發(fā)變得更加輕松。它和CSS Modules的區(qū)別是不再需要CSS樣式文件。
來看一下幾個流行的CSS-in-JS框架六個月內(nèi)的下載趨勢：
我們來看看幾個下載量靠前的框架的風格是什么樣的：
styled-components
先來看看下載量最高的styled-component的代碼風格：
從上圖可以看出，Title和Wrapper都是框架包裝好的component，可以直接在react的jsx語法中使用，在包裝component的時候還定義了標簽分別是h1和section。此段代碼產(chǎn)生的html dom如下圖所示：
可以看到section和h1上分別生成了唯一的class名稱，樣式也對應的定義在生成的class上了。
這樣就可以解決命名混亂和全局污染的問題。組件相關(guān)的代碼都在一起，可以統(tǒng)一查看，也可以方便的重用樣式。
glamorous
再來看看glamorous，這個框架是PayPal開發(fā)的。（前兩個logo看下來，恍惚間感覺進了化妝品專柜）。
和styled-component不同的是，glamorous的樣式直接以attribute的形式定義在了dom上，之后雖然也為其生成了class名稱及樣式，但這種以attribute定義的方式對偽類選擇符（如 :hover）支持的不好，會帶來一些不方便，而且需要再記住一套attributes名稱和值與真正的css樣式代碼的對應關(guān)系。
JSS
和上面兩個框架類似，jss也是會定義styles對象，并附到component上，最后生成的dom也是會有生成的唯一class名稱，并有對應的樣式，但樣式并不是真正的css語法，而是對象的屬性和值，這樣也是對偽類選擇符支持的不好，而且也需要記住屬性和css樣式代碼之間的對應關(guān)系。
Radium
Radium在定義樣式對象上看似和其他相似，但在生成dom結(jié)構(gòu)的時候并沒有生成唯一的class名稱，而是直接把樣式放到了style屬性上，這樣會帶來諸如可讀性差、CSS權(quán)重過大、不支持偽類選擇符等問題。
測試
下面再來看一個styled-component提供的基于jest的測試框架：
這個框架主要是通過生成Snapshot并比較的方式來保證component樣式的每次更改都會被檢測到，并且樣式是期望的樣式。這樣就又降低了重構(gòu)CSS樣式帶來的風險。
優(yōu)劣勢總結(jié)
看了這些框架后，可以發(fā)現(xiàn)CSS-in-JS的優(yōu)勢還是挺多的：
- 因為有了生成的唯一class名稱，避免了全局污染的問題
- 唯一的class名稱也解決了命名規(guī)則混亂的問題
- JavaScript和CSS之間可以變量共享，比如一些基礎(chǔ)的顏色和尺寸，這樣再當需要在JavaScript里計算一些高度的時候，可以取到和dom相關(guān)的一些padding，margin數(shù)值，統(tǒng)一管理
- 只生成頁面需要用到的代碼，縮減了最終包的大小，提升了性能
- CSS的單元測試增加了樣式重構(gòu)的安全性
但是CSS-in-JS也存在著一些不足和爭議：
- 有些觀點覺得JS和CSS的關(guān)系沒這么近，把CSS寫進JS里引入了新的一套依賴，增加了復雜度，新人加入項目后需要學習的東西就更多了，也讓學習曲線更加陡了
- 對前端框架確實有些依賴性，更適合于組件化的框架，如React等
- Debug的時候需要花更多的功夫才能找到對應的樣式代碼
- 覆蓋第三方插件樣式時會有權(quán)重不夠的問題
- Lint工具對于JavaScript內(nèi)部的CSS代碼樣式支持的還不夠
最后
在ThoughtWorks最新一期的技術(shù)雷達(CSS-in-JS | Technology Radar | ThoughtWorks)里，它的等級是Assess，表示的是：“值得追求。重要的是理解如何建立這種能力。企業(yè)應該在風險可控的項目中嘗試此技術(shù)?！?所以最后想說的是，雖然它還是有些不足和爭議，在應用之前需要多角度衡量一下對項目的適合度。但它的優(yōu)點也很多，確確實實解決了很多痛點，而且與web組件化的方向高度一致，希望大家在條件合適的情況下多多嘗試，多多反饋，這樣也能促進整個CSS編碼體驗的繼續(xù)進化~
