你了解 JSX，那你了解 StyleX 么？
大家好，我卡頌。
近日，Meta開源了一款「CSS-in-JS庫」 —— StyleX。看命名方式，Style - X是不是有點像JS - X，他們有關(guān)系么？當(dāng)然有。
JSX是一種「用JS描述HTML」的語法規(guī)范，廣泛應(yīng)用于前端框架中（比如React、SolidJS...），由Meta公司提出。
同樣的，按照Meta的設(shè)想，StyleX是一種「用JS描述CSS」的語法規(guī)范。
早在React Conf 2019[1]，Meta工程師「Frank」就介紹了這種Meta內(nèi)部使用的「CSS-in-JS庫」。
從Meta內(nèi)部使用，到大會對外宣傳，這期間肯定已經(jīng)經(jīng)歷大量內(nèi)部項目的洗禮。而從做完宣傳到最終開源，又經(jīng)歷了快5年時間。
那么，這款Meta出品、打磨這么長時間的「CSS-in-JS庫」，到底有什么特點呢？
本文讓我們來聊聊。
為什么需要CSS解決方案
市面上有非常多「CSS解決方案」，比如：
- BEM命名規(guī)范
- CSS Module規(guī)范
- 原子CSS（比如TailwindCSS）
- CSS-in-JS（比如emotion）
為什么需要這些方案？原生CSS哪里不好？在這里，我們舉個小例子（例子來源于「React Conf 2019」）。考慮如下代碼：
CSS文件如下：
.blue {color: blue;}
.red {color: red;}HTML文件如下：
<p class="red blue">我是什么顏色？</p>請問p標(biāo)簽是什么顏色的？
從class來看，blue在red后面，p應(yīng)該是藍(lán)色的么？
實際上，樣式取決于他們在樣式表中定義的順序，.red的定義在.blue后面，所以p應(yīng)該是紅色的。
是不是已經(jīng)有點暈了？再增加點難度。如果.red和.blue分別在兩個文件中定義呢？
# css文件1
.blue {color: blue;}# css文件2
.red {color: red;}那p的樣式就取決于最終打包代碼中樣式文件的加載順序。
上面只是原生CSS中「選擇器優(yōu)先級相關(guān)的一個缺陷」（除此外還有其他缺陷，比如「作用域缺失」...）。隨著項目體積增大、項目維護(hù)時間變長、項目維護(hù)人員更迭，這些缺陷會被逐漸放大。
正是由于這些原因，才出現(xiàn)了各種「CSS解決方案」。
StyleX的基本使用
StyleX的API很少，掌握下面兩個就能上手使用：
- stylex.create，創(chuàng)建樣式。
- stylex.props，定義props。
比如：
import * as stylex from 'stylex';
// 創(chuàng)建樣式
const styles = stylex.create({
red: {color: 'red'},
});
// 定義props
const redStyleProps = stylex.props(styles.red);使用時：
<div {...redStyleProps}>文字顏色是紅色</div>stylex是如何解決上面提到的red blue優(yōu)先級問題呢？其實很簡單，考慮如下代碼：
import * as stylex from 'stylex';
// 創(chuàng)建樣式
const styles = stylex.create({
red: {color: 'red'},
blue: {color: 'blue'}
});
// 使用
<p {...styles.props(styles.red, styles.blue)}></p>樣式的優(yōu)先級只需要考慮styles.props中的定義順序（blue在red后面，所以顏色為blue），不需要考慮樣式表的存在。
有些同學(xué)會說，看起來和常見的CSS-in-JS沒啥區(qū)別啊。那stylex相比于他們的優(yōu)勢是啥呢？
相比其他CSS-in-JS的優(yōu)勢
首先要明確，stylex雖然以CSS-in-JS的形式存在，但本質(zhì)上他是一種「用JS描述CSS的規(guī)范」。文章開頭也提到，他的定位類似JSX。
既然是規(guī)范，那他就不是對CSS的簡單封裝、增強(qiáng)，而是一套「自定義的樣式編寫規(guī)范」，只不過這套規(guī)范最終會被編譯為CSS。
作為對比，Less、Sass這樣的「CSS預(yù)處理器」就是對CSS語法的封裝、增強(qiáng)
那么，stylex都有哪些規(guī)范呢？
比如，stylex鼓勵將樣式與組件寫在同一個文件，類似Vue的SFC（單文件組件）。這么做除了讓組件的樣式與邏輯更方便維護(hù)，也減少了stylex編譯的實現(xiàn)難度。
再比如，CSS中各種選擇器的復(fù)雜組合增強(qiáng)了選擇器的靈活性。但同時也增強(qiáng)了不確定性。舉個例子，考慮如下三個選擇器：
- .className > *
- .className ~ *
- .className:hover > div:first-child
這些對.className應(yīng)用的選擇器將影響.className的某些后代。當(dāng)這樣的選擇器多了后，很可能會在開發(fā)者不知道的情況下改變某些后代元素的樣式。
遇到這種情況我們一般會怎么處理呢？正確的選擇當(dāng)然是找到上述影響后代的選擇器，再修改他。
但大家工作都這么忙，遇到這種問題，多半就是用新的選擇器覆寫樣式，必要的時候還會加!important后綴。久而久之，這代碼就沒法維護(hù)了。
為了規(guī)避這種情況，在stylex中，除了「可繼承樣式」（指「當(dāng)父元素應(yīng)用后，子孫元素默認(rèn)會繼承的樣式」，比如color）外，不支持這些「可以改變子孫后代樣式的選擇器」。
那我該如何讓子孫組件獲得父組件同樣的樣式呢？通過props透傳啊～
也就是說，stylex禁用了CSS中可能造成混淆的選擇器，用JS的靈活性彌補(bǔ)這部分功能的缺失。
有些同學(xué)可能會說：這些功能，其他「CSS-in-JS庫」也能做啊。
這就要談到「CSS-in-JS庫」最大的劣勢 —— 為了計算出最終樣式，在運(yùn)行時會造成額外的樣式計算開銷。
stylex通過編譯來減少運(yùn)行時的開銷。比如對于上面提到過的stylex的代碼：
import * as stylex from 'stylex';
// 創(chuàng)建樣式
const styles = stylex.create({
red: {color: 'red'},
});
// 定義props
const redStyleProps = stylex.props(styles.red);編譯后的產(chǎn)物包括如下兩部分：
JS的編譯產(chǎn)物：
import * as stylex from 'stylex';
const redStyleProps = {className: 'x1e2nbdu'};CSS的編譯產(chǎn)物：
.x1e2nbdu {
color: red;
}所以，運(yùn)行時實際運(yùn)行的代碼始終為：
<div {...{className: 'x1e2nbdu'}}>...</div>對于再復(fù)雜的樣式，stylex都會通過編譯生成「可復(fù)用的原子類名」。
即使是跨文件使用樣式，比如我們在另一個文件也定義個使用color: 'red'樣式的stylex屬性foo：
import * as stylex from '@stylexjs/stylex';
const styles = stylex.create({
foo: {
color: 'red',
},
bar: {
backgroundColor: 'blue',
},
});會得到如下編譯結(jié)果，其中x1e2nbdu是一個原子類名，他是上一個文件中styles.red的編譯產(chǎn)物：
import * as stylex from '@stylexjs/stylex';
const styles = {
foo: {
color: 'x1e2nbdu',
$$css: true,
},
bar: {
backgroundColor: 'x1t391ir',
$$css: true,
},
};隨著項目體積增大，樣式表的體積也能控制在合理的范圍內(nèi)。這種對原子類名的控制粒度是其他「CSS-in-JS庫」辦不到的。
相比于原子CSS的優(yōu)勢
stylex相比TailwindCSS這樣的原子CSS有什么優(yōu)勢呢？
這就要談到原子CSS的一個特點 —— 使用約定好的字符串實現(xiàn)樣式。比如，使用TailwindCSS定義圖片的樣式：
<img class="w-24 h-24 rounded-full mx-auto" src="/sarah-dayan.jpg" alt="" width="384" height="512">效果如下：
由于樣式都是由不同的「原子類名字符串」組合而成，TS沒法分析，這就沒法實現(xiàn)「樣式的類型安全」。
什么叫「樣式的類型安全」？通俗的講，如果我實現(xiàn)一個組件，組件通過style props定義樣式，我只希望使用者能夠改變color與fontSize兩個樣式屬性，不能修改其他屬性。如果能實現(xiàn)這一點，就是「樣式的類型安全」。
「樣式的類型安全」有什么意義呢？舉個例子：設(shè)想開發(fā)基礎(chǔ)組件庫的團(tuán)隊使用stylex。那么當(dāng)業(yè)務(wù)團(tuán)隊使用該組件庫時，就只能自定義組件的一些樣式（由組件庫團(tuán)隊約束）。
當(dāng)基礎(chǔ)組件庫升級時，組件庫團(tuán)隊能很好對組件樣式向下兼容（因為知道只有哪些樣式允許被修改）。
在stylex中，由于stylex.create的產(chǎn)物本質(zhì)是對象，所以我們可以為每個產(chǎn)物定義類型聲明。比如在如下代碼中，我們限制了組件style props只能接受如下stylex樣式：
import type {StyleXStyles} from '@stylexjs/stylex';
type Props = {
// ...
style?: StyleXStyles<{
color?: string;
backgroundColor?: string;
borderColor?: string;
borderTopColor?: string;
borderEndColor?: string;
borderBottomColor?: string;
borderStartColor?: string;
}>;
};總結(jié)
我猜想，當(dāng)更多人知道stylex后，他會收到比當(dāng)初TailwindCSS火時更多的兩級分化的評價。
畢竟，stylex的設(shè)計初衷是為了解決Meta內(nèi)部復(fù)雜應(yīng)用的樣式管理。如果：
- 你項目沒有達(dá)到Meta這樣的體量
- 你項目沒有多年的迭代周期
- 你項目前前后后沒有多個工程師經(jīng)手
那大概率是不能接受stylex設(shè)計理念中的這些約束。
對于stylex，你怎么看？
參考資料
[1]React Conf 2019:https://www.youtube.com/watch?v=9JZHodNR184&t=270s。
