摘要：原文地址原文作者譯文出自掘金翻譯計劃譯者校對者統(tǒng)一樣式語言在過去幾年中，我們見證了的興起，尤其是在社區(qū)。根本上來說，純粹用于只是一個命名規(guī)范，它要求樣式的類名要遵守的模式。

原文地址：A Unified Styling Language

原文作者：Mark Dalgleish

譯文出自：掘金翻譯計劃

譯者：ZhangFe

校對者：JackGit,yifili09

在過去幾年中，我們見證了 CSS-in-JS 的興起，尤其是在 React 社區(qū)。當(dāng)然，它也飽含爭議。很多人，尤其是那些已經(jīng)對 CSS 非常熟悉的人都表示難以置信。

"為什么有人要在 JS 中寫 CSS？
這簡直是一個可怕的想法！
但愿他們學(xué)過 CSS !"

如果這就是你的反應(yīng)，那么請繼續(xù)讀下去。我們來看看到底為什么在 JavaScript 中編寫樣式并不是一個可怕的想法，并且為什么我認(rèn)為你應(yīng)該關(guān)注這個快速發(fā)展的領(lǐng)域。

React 社區(qū)經(jīng)常被 CSS 社區(qū)誤解，反之亦然。對我來說這很有趣，因為我經(jīng)?；燠E于這兩個社區(qū)。

我從九十年代后期開始學(xué)習(xí) HTML，并且從基于表格布局的黑暗時代以來就一直使用 CSS。受 CSS Zen Garden 啟發(fā)，我是最早一批將現(xiàn)有代碼向 語義化標(biāo)簽 和級聯(lián)樣式表遷移的人。不久之后，我開始專注于前后端分離，使用非侵入式 JavaScript 和客戶端的交互來裝飾服務(wù)端渲染的 HTML。圍繞這些做法有一個小型且充滿活力的社區(qū)，并且我們成為第一代嘗試給瀏覽器平臺應(yīng)有尊重的前端開發(fā)者。

伴隨這樣的背景，你可能會認(rèn)為我會強烈反對 React 的 HTML-in-JS 模式，它似乎違背了我們所堅持的原則，但實際上恰恰相反。根據(jù)我的經(jīng)驗，React 的組件模型加上服務(wù)端渲染的能力，最終給我們提供了一種構(gòu)建大規(guī)模復(fù)雜單頁應(yīng)用的方式，從而使我們能夠?qū)⒖焖伲稍L問，逐漸增強的應(yīng)用推送給我們的用戶。在 SEEK 上我們就利用了這種能力，這是我們的旗艦產(chǎn)品，它是 React 單頁應(yīng)用程序，當(dāng) JavaScript 被禁用時我們的核心搜索流程依然可用，因為我們通過在服務(wù)器端運行同構(gòu)的 JavaScript 代碼來完成到傳統(tǒng)的網(wǎng)站優(yōu)雅降級。

所以，也請考慮一下我拋出的從一個社區(qū)到另一個社區(qū)的橄欖枝。讓我們一起嘗試?yán)斫膺@個轉(zhuǎn)變。它可能不完美，它可能不是你計劃在產(chǎn)品中使用的東西，它可能對你不是很有說服力，但是至少值得你嘗試思考一下。

如果你熟悉我最近做的與 React 以及 CSS 模塊相關(guān)的工作，當(dāng)看到我維護(hù) CSS-in-JS 時你可能會很驚訝。

畢竟，通常那些希望有局部樣式但是又不希望在 JS 中寫 CSS 的開發(fā)者會選擇使用 CSS 模塊。事實上，甚至我自己在工作中也還沒用到 CSS-in-JS。

盡管如此，我任然對 CSS-in-JS 社區(qū)保持濃厚的興趣，對他們不斷提出的創(chuàng)意保持密切關(guān)注。不僅如此，我認(rèn)為更廣泛的 CSS 社區(qū)對它也應(yīng)該很感興趣

原因是什么呢?

為了更清楚地了解為什么人們選擇在 JavaScript 中編寫他們的樣式，我們將重點關(guān)注采用這種方式時帶來的實際好處。

我把它分為五個方面:

局部樣式

關(guān)鍵 CSS

智能優(yōu)化

打包管理

在非瀏覽器環(huán)境下的樣式

讓我們進(jìn)一步的細(xì)分并且仔細(xì)看看 CSS-in-JS 提供的每一點優(yōu)勢。

想要在大規(guī)模項目中高效的構(gòu)建 CSS 是非常困難的。當(dāng)加入一個現(xiàn)有的長期運行的項目時，通常我們會發(fā)現(xiàn) CSS 是系統(tǒng)中最復(fù)雜的部分。

為了解決這個問題，CSS 社區(qū)已經(jīng)投入了巨大的努力，通過 Nicole Sullivan 的 OOCSS 和 Jonathan Snook 的 SMACSS 都可以使我們的樣式更好維護(hù)，不過 Yandex 開發(fā)的 BEM 更流行一些。

根本上來說，BEM （純粹用于 CSS）只是一個命名規(guī)范，它要求樣式的類名要遵守 .Block__element--modifier 的模式。在任何使用 BEM 風(fēng)格的代碼庫中，開發(fā)人員必須始終遵守 BEM 的規(guī)則。當(dāng)嚴(yán)格遵守時，BEM 的效果很好，但是為什么這些如同作用域一般基礎(chǔ)的功能，卻只使用單純的命名規(guī)范來限制呢？

無論是否有明確表示，大多數(shù) CSS-in-JS 類庫都遵循 BEM 的思路，它們嘗試將樣式定位到單個 UI 組件，只不過用了完全不同的實現(xiàn)方式。

那么在實際編寫代碼時什么樣的呢？當(dāng)使用 Sunil Pai 開發(fā)的 glamor 時，代碼看起來像下面這樣：

import { css } from "glamor"
const title = css({
  fontSize: "1.8em",
  fontFamily: "Comic Sans MS",
  color: "blue"
})
console.log(title)
// → "css-1pyvz"

你可能會注意到代碼中沒有 CSS 的類名。因為它不再是一個指向定義在項目其他位置 class 的硬編碼，而是由我們的庫自動生成的。我們不必再擔(dān)心全局作用域內(nèi)的選擇器沖突，這也意味著我們不再需要替他們添加前綴了。

這個選擇器的作用域與周圍代碼的作用域一致。如果你希望在你應(yīng)用的其他地方使用這個規(guī)則，你就需要將它改寫成一個 JavaScript 模塊并且在需要使用的地方引用它。就保持代碼庫的可維護(hù)性而言，它是非常強大的，它確保了任何給定的樣式都可以像其他代碼一樣容易追蹤來源。

通過從僅僅是命名約定到默認(rèn)強制局部樣式的轉(zhuǎn)變，我們已經(jīng)提高了我們樣式質(zhì)量的基準(zhǔn)線。BEM 已經(jīng)烙在里面了，而不再是一個可選項。

—

在繼續(xù)之前，我要說明至關(guān)重要的一點。

它生成的是真正的級聯(lián)樣式，而不是內(nèi)聯(lián)樣式

大多數(shù)早期的 CSS-in-JS 庫都是將樣式直接添加到每個元素上，但是這個模式有個嚴(yán)重的缺點，"styles" 屬性并不能做到 CSS 可以做到的每件事。大多數(shù)新的庫不再關(guān)注于動態(tài)樣式表，而是在運行時在全局樣式中插入和刪除規(guī)則。

舉個例子，讓我們看看 Oleg Slobodskoi 開發(fā)的 JSS，這是最早的 CSS-in-JS 庫之一，并且它生成的是真實的 CSS。

當(dāng)使用 JSS 時，你可以使用標(biāo)準(zhǔn)的 CSS 特性，比如 hover 和媒體查詢，它們會映射到相應(yīng)的 CSS 規(guī)則。

const styles = {
  button: {
    padding: "10px",
    "&:hover": {
      background: "blue"
    }
  },
  "@media (min-width: 1024px)": {
    button: {
      padding: "20px"
    }
  }
}

一旦你將這些樣式插入到文檔中，你就可以使用那些自動生成的類名。

const { classes } = jss.createStyleSheet(styles).attach()

無論你是使用一個完整的框架，還是簡單的使用 innerHTML，你都可以在 JavaScript 中使用這些生成的 class，而不是硬編碼你的 class 字符串。

document.body.innerHTML = `
  
Hello World!
`

多帶帶使用這種方式管理樣式并沒有多大的優(yōu)勢，它通常和一些組件庫搭配使用。因此，通常可以找到用于最流行庫的綁定方案。例如，JSS 可以通過 react-jss 的幫助輕松地綁定到 React 組件上，在管理生命周期的同時，它可以幫你給每個組件插入一小段樣式。

import injectSheet from "react-jss"
const Button = ({ classes, children }) => (
  
    
      {children}
    
  
)
export default injectSheet(styles)(Button)

通過將我們的樣式集中到組件上，可以將他們和代碼跟緊密的結(jié)合，這不就是 BEM 的思想么？所以 CSS-in-JS 社區(qū)的很多人覺得在所有的樣式綁定樣板中，提取、命名和復(fù)用組件的重要性都丟失了。

隨著 Glen Maddern 和 Max Stoiber 提出了 styled-components 的概念，出現(xiàn)了一個新的思考這個問題的方式。

我們直接創(chuàng)建組件，而不是創(chuàng)建樣式然后手動地將他們綁定到組件上。

import styled from "styled-components"

const Title = styled.h1`
  font-family: Comic Sans MS;
  color: blue;
`

使用這些樣式時，我們不會將 class 添加到存在的元素上，而是簡單地渲染這些被生成的組件。

雖然 styled-components 通過模板字面量的方式使用了傳統(tǒng)的 CSS 語法，但是有人更喜歡使用數(shù)據(jù)結(jié)構(gòu)。來自 PayPal 的 Kent C. Dodds 開發(fā)的 Glamorous 是一個值得關(guān)注的替代方案。

Glamorous 和 styled-components 一樣提供了組件優(yōu)先的 API，但是他的方案是使用對象而不是字符串，這樣就無需在庫中引入一個 CSS 解析器，可以降低庫的大小并提高性能。

import glamorous from "glamorous"

const Title = glamorous.h1({
  fontFamily: "Comic Sans MS",
  color: "blue"
})

無論你使用什么語法描述你的樣式，他們不再僅僅是組件的一部分，他們和組件已經(jīng)無法分離。當(dāng)使用一個像 React 這樣的庫時，組件是基本構(gòu)建塊，并且現(xiàn)在我們的樣式也成了構(gòu)建這個架構(gòu)的核心部分。如果我們將我們應(yīng)用程序中的所有內(nèi)容都描述為組件，那么為什么我們的樣式不行呢？

—

考慮到我們之前介紹的對系統(tǒng)做出改變的意義，對于那些有豐富 BEM 開發(fā)經(jīng)驗的工程師來說，這一切看起來似乎是一個很小的提升。事實上，CSS 模塊讓你在不用放棄 CSS 工具生態(tài)系統(tǒng)的同時獲得了這些提升。很多項目堅持使用 CSS 模塊還有一個原因，他們發(fā)現(xiàn) CSS 模塊充分解決了編寫大規(guī)模 CSS 的問題，并且可以保持編寫常規(guī) CSS 時的習(xí)慣。

然而，當(dāng)我們開始在這些基本概念上構(gòu)建時，事情開始變得更有趣。

在文檔頭部內(nèi)聯(lián)關(guān)鍵樣式已經(jīng)成為一種比較新的最佳實踐，通過僅提供當(dāng)前頁面所需的樣式可以提高首屏?xí)r間。這與我們常用的樣式加載方式形成了鮮明對比，之前我們通常會強制瀏覽器在渲染之前為應(yīng)用下載所有的樣式。

雖然有工具可以用于提取和內(nèi)聯(lián)關(guān)鍵 CSS，比如 Addy Osmani 的 critical，但是他們無法從根本上改變關(guān)鍵 CSS 難以維護(hù)和難以自動化的事實。這是一個棘手的、可選的性能優(yōu)化，所以大部分項目似乎放棄了這一步。

CSS-in-JS 則是一個完全不同的故事。

當(dāng)你的應(yīng)用使用服務(wù)端渲染時，提取關(guān)鍵 CSS 不僅僅是一個優(yōu)化，從根本上來說，服務(wù)器端的 CSS-in-JS 是使用關(guān)鍵 CSS 的首要工作。

舉個例子，當(dāng)使用 Khan Academy 開發(fā)的 Aphrodite 給元素添加 class 時，可以通過內(nèi)聯(lián)調(diào)用它的 css 函數(shù)來跟蹤在這次渲染過程中使用的樣式。

import { StyleSheet, css } from "aphrodite"
const styles = StyleSheet.create({
  title: { ... }
})
const Heading = ({ children }) => (
  
{ children }
)

即便你所有的樣式都是在 JavaScript 中定義的，你也可以很輕松的從當(dāng)前頁面中提取所有的樣式并生成一個 CSS 字符串，在執(zhí)行服務(wù)端渲染時將它們插入文檔的頭部。

import { StyleSheetServer } from "aphrodite";

const { html, css } = StyleSheetServer.renderStatic(() => {
  return ReactDOMServer.renderToString();
});

你可以像這樣渲染你的關(guān)鍵 CSS：

const criticalCSS = `
  
`;

如果你看過 React 的服務(wù)端渲染模型，你可能會發(fā)現(xiàn)這個模式非常熟悉。在 React 中，你的組件在 JavaScript 中定義他們的標(biāo)記，但可以在服務(wù)器端渲染成常規(guī)的 HTML 字符串。

如果你使用漸進(jìn)增強的方式構(gòu)建你的應(yīng)用，盡管全部使用 JavaScript 編寫，但也有可能在客戶端根本就不需要 JavaScript

無論用哪種方式，客戶端 JavaScript bundle 都要包含啟動單頁應(yīng)用所需的代碼，它能讓頁面瞬間活起來，并與此同時開始瀏覽器中進(jìn)行渲染。

由于在服務(wù)器上渲染 HTML 和 CSS 是同時進(jìn)行的，就像前面的例子所示， Aphrodite 這樣的庫通常會以一個函數(shù)調(diào)用的方式幫助我們流式生成關(guān)鍵 CSS 和服務(wù)端渲染的 HTML?，F(xiàn)在，我們可以用類似的方式將我們的 React 組件渲染成靜態(tài) HTML。

const appHtml = `
  

    ${html}
  
`

通過在服務(wù)器端使用 CSS-in-JS，我們的單頁應(yīng)用不僅可以脫離 JavaScript 工作，它甚至可以加載的更快。

與我們選擇器的作用域一樣，渲染關(guān)鍵 CSS 的最佳實踐如今已經(jīng)烙在里面了，而不是一個可選項。

我們最近看到了構(gòu)建 CSS 的新方式的興起，比如 Yahoo 的 Atomic CSS 和 Adam Morse 的 Tachyons，它們更喜歡短小的，單一用途的類名，而不是語義化的類名。舉個例子，當(dāng)使用 Atomic CSS 時，你將使用類似于函數(shù)調(diào)用的語法去作為類名，并且這些類名會在之后被用來生成合適的樣式表。

  Atomic CSS

通過最大程度地提高類的復(fù)用性以及用內(nèi)聯(lián)樣式的方式一樣有效處理類名，可以達(dá)到盡可能地精簡 CSS 的目的。雖然文件大小的減少很容易體現(xiàn)，但對于你的代碼庫和團(tuán)隊成員的影響確實是微乎其微的。這些優(yōu)化會從底層引起你的 CSS 和標(biāo)記語言的變化，使他們成為構(gòu)建工作中更重要的部分。

正如我們已經(jīng)介紹過的，當(dāng)使用 CSS-in-JS 或者 CSS 模塊時，你不再需要在 HTML 中硬編碼你的類名，而是動態(tài)引用由庫或者構(gòu)建工具自動生成的 JavaScript 變量。

我們這樣寫樣式:

而不是:

這個變化可能看起來相當(dāng)膚淺，但是從如何管理標(biāo)記語言和樣式之間關(guān)系上來說，這卻是一個里程碑式的改變。通過給我們的 CSS 工具不止修改樣式，還能修改最終提供給組件的 class 的能力，我們?yōu)槲覀兊臉邮奖斫怄i了一個全新的優(yōu)化方式。

如果看看上面的例子，就會發(fā)現(xiàn) "styles.sidebar" 對應(yīng)了一個字符串，但并沒有什么去限制它只能是一個 class。就我們所了解的，它可以很容易的對應(yīng)成表示十幾個 class 的字符串。

如果我們可以優(yōu)化我們的樣式，為每一套樣式生成多個類，我們就可以做一些非常有趣的事。

我最喜歡的例子是 Ryan Tsao 編寫的 Styletron。

與 CSS-in-JS 和 CSS 模塊自動添加 BEM 風(fēng)格前綴的過程相同，Styletron 對 Atomic CSS 也做了相同的事。

它的核心 API 專注于一件事，為每個由屬性、值、媒體查詢組合起來的樣式定義一個獨立的 CSS 規(guī)則，然后返回自動生成的 class。

import styletron from "styletron";
styletron.injectDeclaration({
  prop: "color",
  val: "red",
  media: "(min-width: 800px)"
});
// → "a"

當(dāng)然，Styletron 也提供了一些高級 API，比如它的 injectStyle 函數(shù)允許一次定義多個規(guī)則。

import { injectStyle } from "styletron-utils";
injectStyle(styletron, {
  color: "red",
  display: "inline-block"
});
// → "a d"
injectStyle(styletron, {
  color: "red",
  fontSize: "1.6em"
});
// → "a e"

尤其要注意上面生成的類名之間的相同點。

通過放棄對 class 本身的低級控制，而僅定義所需要的樣式集合，這些庫就能幫我們生成最佳的 class 原子集合。

之前我們通過手工查找的方式將樣式分割成可復(fù)用的 class，現(xiàn)在已經(jīng)可以完全自動化的完成這種優(yōu)化了，并且你應(yīng)該也開始注意到這個趨勢。原子性 CSS 已經(jīng)烙在里面了，并非一個可選項。

在談?wù)撨@一點之前，我們先停下來問自己一個看似簡單的問題。

我們?nèi)绾喂蚕?CSS？

我們已經(jīng)從手動下載 CSS 文件向使用前端專門的模塊管理工具轉(zhuǎn)變，比如 Bower，或者現(xiàn)在通過 npm 可以使用 Browserify 和 webpack。雖然這些工具已經(jīng)自動處理了外部模塊的 CSS 依賴，但是目前前端社區(qū)大多還是手工處理 CSS 的依賴關(guān)系。

無論使用哪種方式，CSS 之間的依賴都不是很好處理。

你們許多人可能還記得，在使用 Bower 和 npm 管理 JavaScript 模塊時，出現(xiàn)過類似的情況。

Bower 沒有依賴任何特定的模塊格式，而發(fā)布到 npm 的模塊則要求使用 CommonJS 模塊格式。這種不一致，對發(fā)布到兩者任何一個平臺的包的數(shù)量都產(chǎn)生了巨大的影響。

小型但是有復(fù)雜依賴關(guān)系的模塊更愿意使用 npm，Bower 則吸引了大量大型而獨立的模塊，當(dāng)然，你可能也就有兩三個模塊，再加幾個插件，但由于在 Bower 中你的依賴沒有一個模塊系統(tǒng)去作支撐，每個包無法簡單的利用它自己的依賴關(guān)系，所以在整合這一塊，基本上就留給開發(fā)者手動去操作了。

因此，隨著時間的推移，npm 上的模塊數(shù)量呈指數(shù)性增長，而 Bower 只能是有限的線性增長。雖然這可能是各種原因?qū)е碌?，但是不得不說，主要原因還是在于兩個平臺處理運行時包與包之間的依賴關(guān)系的不同方法。

很不幸，這對于 CSS 社區(qū)來說太熟悉了，我們發(fā)現(xiàn)相對于 npm 上的 JavaScript 來說，獨立 CSS 模塊的數(shù)量也增長的很慢。

如果我們也想實現(xiàn) npm 的指數(shù)增長該怎么做？如果我們想依賴不同大小不同層次的復(fù)雜模塊，而不是專注于大型、全面的框架呢？為了做到這一點，我們不僅需要一個包管理器，還需要一個合適的模塊格式。

這是否意味著我們需要專門為 CSS 或者 Sass 和 Less 這樣的預(yù)處理器設(shè)計一個包管理工具？

有趣的是，在 HTML 上我們已經(jīng)實現(xiàn)了類似的功能。如果你問我相同的問題：我們?nèi)绾喂蚕順?biāo)記語言？你可能很快會想起來，我們幾乎不會直接共享原始的 HTML —— 我們共享 HTML-in-JS。

我們通過 jQuery 插件，Angular 指令集 和 React 組件實現(xiàn)了這個功能。我們的大組件由小組件組成，每一個小組件都有著自己的 HTML，它們也都獨立的發(fā)布在了 npm 上。HTML 這種格式可能不足以強大到完成這個功能，但是通過將 HTML 嵌入到完整的編程語言中，我們就可以很輕松的越過這個限制。

我們能不能像 HTML 那樣，通過 JavaScript 去分享 CSS呢？能不能使用函數(shù)來返回對象和字符串而不是使用 mixins ？又或者我們利用 Object.assign 和新的 object spread 操作符 來 merge 對象而不是用 extending classes 呢？

const styles = {
  ...rules,
  ...moreRules,
  fontFamily: "Comic Sans MS",
  color: "blue"
}

一旦我們開始用這種方式編寫我們的樣式，我們就可以使用相同的模式、相同的工具、相同的基礎(chǔ)架構(gòu)、相同的生態(tài)系統(tǒng)來編寫和分享我們的樣式代碼，就像我們應(yīng)用程序中的其他任何代碼一樣。

由 Max Stoiber、Nik Graf 和 Brian Hough 開發(fā)的 Polished 就是一個很好的例子。

Polished 就像是 CSS-in-JS 界的 Lodash，它提供了一整套完整的 mixins、顏色函數(shù)等等，使得在 JavaScript 中可以得到使用 Sass 編寫樣式的體驗。最大的區(qū)別在于，現(xiàn)在這些代碼在復(fù)用、測試和分享方面，都提高了一個層次，并且能夠完整的使用 JavaScript 模塊生態(tài)系統(tǒng)。

當(dāng)談到 CSS 時我們會想，作為一個由小型可復(fù)用的開源模塊組合成的一個樣式集合，我們?nèi)绾潍@得和 npm 上其他模塊相似的開源程度？奇怪的是，我們最終通過將我們的 CSS 嵌入其他的語言并且完全擁抱 JavaScript 模塊實現(xiàn)了這一點。

到目前為止，我的文章已經(jīng)涵蓋了所有的要點，雖然在 JavaScript 中編寫 CSS 會容易的多，但是常規(guī)的 CSS 并非完不成這些功能。這也是我把最有趣、最面向未來的一點留到現(xiàn)在的原因。這一點并不一定能在如今的 CSS-in-JS 社區(qū)中發(fā)揮巨大的作用，但它可能會成為未來設(shè)計的基礎(chǔ)層面。它不僅會影響開發(fā)人員，也會影響設(shè)計師，最終它將改變這兩個領(lǐng)域相互溝通的方式。

首先，為了介紹它，我們需要先簡單介紹一下 React。

—

React 的理念是用組件作為最終渲染的中間層。在瀏覽器中工作時，我們構(gòu)建復(fù)雜的虛擬 DOM 樹而不是直接操作 DOM 元素。

有趣的是，DOM 渲染相關(guān)的代碼并不屬于 React 的核心部分，而是由 react-dom 提供的。

import { render } from "react-dom"

盡管最初 React 是為 DOM 設(shè)計的，并且大部分情況下還是在瀏覽器中使用，但是這種模式也允許 React 只通過簡單地引入新的渲染引擎就能從容面對各種不同的使用環(huán)境。

JSX 不僅僅可以用于虛擬 DOM，他可以用在任何的虛擬視圖上。

這就是 React Native 的工作原理，我們通過編寫那些渲染成 native 的組件以實現(xiàn)用 JavaScript 編寫真正的 native 應(yīng)用，比如我們用 View 和 Text 取代了 div 和 span。

從 CSS 的角度來看，React 最有趣的就是它擁有自己的 StyleSheet API。

var styles = StyleSheet.create({
  container: {
    borderRadius: 4,
    borderWidth: 0.5,
    borderColor: "#d6d7da",
  },
  title: {
    fontSize: 19,
    fontWeight: "bold",
  },
  activeTitle: {
    color: "red",
  }
})

在這里你會看到一組熟悉的樣式，我們編寫了顏色、字體和邊框樣式。

這些規(guī)則都非常簡單，并且很容易映射到大部分的 UI 環(huán)境上，但是當(dāng)涉及到 native 布局時，事情就變得非常有趣了。

var styles = StyleSheet.create({
  container: {
    display: "flex"
  }
})

因為在瀏覽器環(huán)境之外，所以 React Native 有自己的 flexbox 實現(xiàn)

最初發(fā)布時他是一個名為 css-layout 的JavaScript 模塊，完全用 JavaScript 重新實現(xiàn)了 flexbox（包含充分的測試），為了更好的可移植性它現(xiàn)在已經(jīng)遷移到 C 語言。

鑒于這個項目的影響力和重要性，它被賦予了更重要的品牌 ——— Yoga。

雖然 Yoga 專注于將 CSS 遷移到非瀏覽器環(huán)境中，但是僅關(guān)注于 CSS 特性的一小部分無法擴大它的統(tǒng)治范圍。

"Yoga 的重點是成為一個有表現(xiàn)力的布局框架，而不是去實現(xiàn)一套完整的 CSS"

這看起來似乎很難實現(xiàn)，但是當(dāng)你回顧 CSS 體系的歷史時會發(fā)現(xiàn)使用 CSS 進(jìn)行規(guī)?；墓ぷ骶褪沁x擇一個合適的語言子集。

在 Yoga 中，為了控制樣式的作用域，他們避開了級聯(lián)樣式，并且將布局引擎完全集中在 flexbox 上。雖然這樣會喪失很多功能，但它也為需要嵌入樣式的跨平臺組件創(chuàng)造了驚人的機遇，我們已經(jīng)看到幾個試圖利用這個特性的開源項目。

Nicolas Gallagher 開發(fā)的 React Native for Web 旨在成為 react-native 的一個替代品。當(dāng)使用 webpack 這類打包工具時，很容易用別名來替換第三方庫。

module: {
  alias: {
    "react-native": "react-native-web"
  }
}

使用 React Native for Web 后可以在瀏覽器環(huán)境中運行 React Native 組件，包括 React Native 樣式 API

同樣，Leland Richardson 開發(fā)的 react-primitives 也提供了一套跨平臺的原始組件，它可以抽象目標(biāo)平臺的實現(xiàn)細(xì)節(jié)，為跨平臺組件創(chuàng)造可行的標(biāo)準(zhǔn)。

甚至 微軟 也開始推出 ReactXP，這個庫旨在簡化跨 web 和 native 的工作流，它也有自己的跨平臺樣式實現(xiàn)

—

即使你不編寫 native 應(yīng)用程序，也要注意一點：擁有一個真正的跨平臺組件抽象，能夠使我們將目標(biāo)設(shè)定在那些高效的、無限可能的環(huán)境中去，有時這些會讓你無法想象。

我所見過的最令人震驚的例子是 Airbnb 的 Jon Gold 開發(fā)的 react-sketchapp。

我們很多人都花費了大量時間去嘗試標(biāo)準(zhǔn)化我們的設(shè)計語言，并且盡可能的避免系統(tǒng)中的重復(fù)。不幸的是，盡管我們希望樣式只有一個來源，但我們最多也只能減少到兩個，開發(fā)人員的動態(tài)樣式以及設(shè)計師的靜態(tài)樣式。雖然這已經(jīng)比我們之前的模式好了很多，但是它仍然需要我們手工的將樣式從 Sketch 這樣的設(shè)計工具上同步到代碼里。這也是 react-sketchapp 被開發(fā)出來的原因。

感謝 Sketch 的 JavaScript API，以及 React 連接到不同渲染引擎的能力，react-sketchapp 讓我們可以用跨平臺的 React 組件渲染我們的 Sketch 文件。

不用多說，這很可能改變設(shè)計師和開發(fā)人員的合作方式?，F(xiàn)在，當(dāng)我們對設(shè)計進(jìn)行迭代時，無論在設(shè)計工具還是開發(fā)者工具上，我們都可以通過相同的聲明引用同一個組件。

通過 Sketch 中的符號和 React 中的組件，我們的行業(yè)已經(jīng)開始從本質(zhì)上趨于抽象，并且通過使用相同的工具我們可以更緊密的協(xié)作。

這么多新的嘗試都來自 React 和其周邊的社區(qū)，看來這并不是巧合。

在組件架構(gòu)中，最重要的是將組件的功能集中在一起。這自然包括它的局部樣式，往更復(fù)雜的方向延伸就涉及到數(shù)據(jù)的獲取。這里要感謝 Relay 和 Apollo，讓這個過程變得簡單。這些成果解鎖了巨大了潛力，我們現(xiàn)在所了解的，只是其中冰山一角。

雖然這對我們編寫樣式產(chǎn)生了很大的影響，但其實它對我們架構(gòu)里的一切都有很大的影響，當(dāng)然，是出于好的理由。

通過統(tǒng)一單一語言開發(fā)組件的模式，我們能夠從功能上，而不是從技術(shù)上，將我們的關(guān)注點進(jìn)行更好的隔離。將組件的所有內(nèi)容局部化，用他們構(gòu)建大型可維護(hù)的系統(tǒng)，用之前無法使用的方式進(jìn)行優(yōu)化，更容易的分享我們的工作，以及利用小型開源模塊構(gòu)建大型應(yīng)用程序。更重要的是，完成這一切并不需要打破漸進(jìn)增強的理念，也不會讓我們放棄認(rèn)真對待 web 平臺的理念。

最重要的是，我對使用單一語言編寫出的組件的潛力感到興奮，他們形成了一種新的、統(tǒng)一的樣式語言基礎(chǔ)，以一種前所未有的方式統(tǒng)一了前端社區(qū)。

在 SEEK，我們正在努力利用這一功能，我們圍繞組件模型來構(gòu)建在線樣式指南，其中語義化、交互性和視覺風(fēng)格都有統(tǒng)一的抽象。這構(gòu)成了開發(fā)人員和設(shè)計師之間共享的通用設(shè)計語言。

構(gòu)建一個頁面應(yīng)該盡可能的和拼裝組件一樣簡單，這樣可以確保我們工作的高品質(zhì)，并且讓我們在產(chǎn)品上線很久以后，也有能力去升級其設(shè)計語言。

import {
  PageBlock,
  Card,
  Text
} from "seek-style-guide/react"
const App = () => (
  
    
      Hello World!
    
  
)

盡管我們現(xiàn)在使用 React，webpack 和 CSS 模塊構(gòu)建了這個樣式指南，但是這個架構(gòu)，和任何你之前知道的 CSS-in-JS 系統(tǒng)是一致的。技術(shù)上可能不一致，但是核心理念是一樣的。

然而，未來這些技術(shù)選型可能也需要以一種意想不到的方式進(jìn)行轉(zhuǎn)變，這也就是為什么保持對這個領(lǐng)域的持續(xù)關(guān)注，對與我們不斷發(fā)展的組件生態(tài)是如此的重要。我們現(xiàn)在可能不會用 CSS-in-JS 這項技術(shù)，但是很可能沒過多久就會出現(xiàn)一個令人信服的理由讓我們使用它。

CSS-in-JS 在短時間里有了出人意料的發(fā)展，但更重要的是，它只是這個宏偉藍(lán)圖的開始。

它還有很大的改進(jìn)空間，并且它的創(chuàng)新還沒有停止的跡象。新的庫正不斷涌現(xiàn)，它們解決了未來會出現(xiàn)的問題并且提升了開發(fā)人員的體驗 —— 比如性能的提升，在構(gòu)建時抽取靜態(tài) CSS，支持 CSS 變量以及降低了前端開發(fā)人員的入門門檻。

這也是 CSS 社區(qū)關(guān)注的地方。盡管這些對我們的工作流程有很大的改動，但是他們不會改變你仍然需要學(xué)習(xí) CSS 的事實。

我們可能使用不同的語法，也可能以不同的方式構(gòu)建我們的應(yīng)用，但是 CSS 的基本構(gòu)建塊不會消失。同樣，我們行業(yè)向組件架構(gòu)的轉(zhuǎn)變是不可避免的，通過這種方式重新構(gòu)想前端的意愿只會越來越強烈。我們非常需要共同合作以確保我們的解決方案廣泛適用于各種背景的開發(fā)人員，無論是專注于設(shè)計的還是工程的。

雖然有時我們的觀點不一致，但是 CSS 和 JS 社區(qū)對于改進(jìn)前端，把 Web 平臺變得更加重要以及改進(jìn)我們下一代 web 開發(fā)流程都有很大的激情。社區(qū)的潛力是巨大的，而且盡管到目前為止我們已經(jīng)解決了大量的問題，仍然有很多工作還沒有完成。

到這里，可能你還是沒有被說服，但是完全沒關(guān)系。雖然現(xiàn)在在工作上使用 CSS-in-JS 不是很合適，但我希望它有合適的原因，而不是僅僅因為語法就反對它。

無論如何，未來幾年這種編寫樣式的風(fēng)格可能會越來越流行，并且值得關(guān)注的是它發(fā)展的非?？?。我衷心希望你可以加入我們，無論是通過貢獻(xiàn)代碼還是簡單的參與我們的對話討論，都能讓下一代 CSS 工具盡可能的提高前端開發(fā)人員的工作效率?；蛘?，我希望已經(jīng)讓你們至少了解為什么人們對這一塊如此飽含激情，或者，至少了解為什么這不是一個愚蠢的點子。

掘金翻譯計劃 是一個翻譯優(yōu)質(zhì)互聯(lián)網(wǎng)技術(shù)文章的社區(qū)，文章來源為 掘金 上的英文分享文章。內(nèi)容覆蓋 Android、iOS、React、前端、后端、產(chǎn)品、設(shè)計 等領(lǐng)域，想要查看更多優(yōu)質(zhì)譯文請持續(xù)關(guān)注 掘金翻譯計劃。