關于 React ：你不可不知的 19 件事兒

作者 | Anthony Morris

譯者 | 王強

策劃 | 王文婧

這篇文章是我個人對本屆 React Conf 的一些精華總結。所有講座都值得一看，是以我建議大家回顧第一天和第二天的所有錄像 [1]。我在文末給每個講座都注明了視訊時間戳。

總結的有些内容可能會讓你感到驚訝，其實我也是！這些内容并不都是技術主題的，但是都貫穿着同一條主線。

一切都是為了服務于開發者體驗

Tom Occhino 提到這個話題後我就一直在思考它。其實所有演講中都能看到這種思想的影子，這也是為什麼我如此熱愛開發工具和前端的原因所在。

React 旨在創造一種開發體驗，使開發者們能夠更加輕松的學習并實作更加強大的功能，通過更快的疊代來提高生産力，以及提升開發軟體的規模。這些事情使我像 React 一樣。我覺得 Facebook 在傳遞方面做得很好。

這一切有什麼意義呢？很簡單，我們做這些就是為了改善使用者體驗，為了提升使用者的生産力。我們要幫助他們，讓他們用優雅的方式來實作目标。雖然我們背後要做的工作可能不會都那麼輕松，但我們應該讓使用者感受到如沐春風。

由于 React 是一種網關技術，而且有 63％的 JavaScript 開發人員正在使用它，是以他們的團隊非常重視社群。他們通過了《貢獻者公約》[2]，歡迎大家提出批評。作為一個社群，我們應該能夠接受批評，而不是處處為自己辯護。Elbert Hubbard 說：“不想要批評的話，除非我們什麼都不說、什麼都不做、什麼都不承擔。” React 所做的事情以及其原因才是關鍵所在。這自然會招緻批評，進而讓技術不斷成長。

令人欣喜的易用性、性能和并發模式

你在使用 React 時是否遇到過焦點問題？我就遇到過。焦點确實很重要 [3]，原因有很多，它可以幫助人們浏覽頁面，這對不用滑鼠的使用者來說非常重要，稍後會再讨論這個話題。總之我們很高興看到 React 團隊準備将可通路性納入架構之中。

大會期間我思考最多的事情之一就是性能。Facebook 要處理的一些性能問題是我們大多數人永遠都遇不到的，但他們從這些教訓中所學到的知識仍然可以用來改善使用者體驗。重點在于感覺到的速度，而不是單純的頁面加載延遲。

Yuzhi Zheng 在她的演講中講了選擇性 Hydration 的例子 [4]。你可能也聽說過 Suspense，它能改善 Web 上的整體使用者體驗。

并發模式

假如我們要制作一個關聯使用者輸入的可過濾清單。用 React 來做時，除非你不在乎性能，否則你就得對清單的更新做防抖和優化。

并發模式能讓 React 對低優先級的工作中斷響應，進而提升 React 應用的響應速度。這使得使用者輸入之類的事情，比重新渲染清單之類的事情具備更高的優先級。React 将可以同時處理多個狀态更新，這将幫助我們消除卡頓和過于頻繁的 DOM 更新，還可以讓我們能優先處理懸停和文本輸入之類的互動，我們知道使用者希望這些内容能夠快速的被處理處理。

React 團隊分享了許多并發模式的示例，建議參考下方連結。

https://reactjs.org/docs/concurrent-mode-patterns.html

CSS-in-JS-at-FB

Frank Yan 宣布 Facebook 正在建構自己的 CSS-in-JS 庫，我很感興趣。剛開始我覺得難道我們目前的庫還不夠嗎？這使我們有機會進一步了解 Facebook 面臨的一些擴充問題，以及他們解決問題的創造性方式。

CSS 的維護工作很容易失控。來看下面的例子：

.blue { color: blue; }

.red { color: red; }

<span class="red blue">
Which color will I be?
</span>

示例中，我們希望文本結果為 blue。因為這個類在類聲明中排第二，是以我們應該可以認為它具有優先權。但事實并非如此。.red 類在層疊樣式表中排第二，是以會優先展示為紅色。如果這些類位于不同的樣式表中，則它們在頁面中的加載順序就會很重要。這個例子很簡單，但這麼簡單的問題也會失控。Facebook 想靠他們的新的庫來解決特異性戰争、主題化和可通路性之類的問題。

演講中的一些有趣的細節：

開發人員能以像素為機關來編碼，然後在 REM 中編譯；

他們通過實作類型檢查（捕獲和修複錯字、檢測和删除未使用的樣式、避免跨浏覽器陷阱）來提升安全性；

向開發人員顯示可通路性錯誤；

元件可以有能被覆寫的預設樣式（包括類型安全！）；

重複規則會被移除，這樣 CSS 檔案就能瘦身了（Facebook 最近重寫了前端，從 413kb 瘦身到 74kb）。

原子 CSS

每個類都建立一個唯一的屬性值，這是用來優化元件的。

https://youtu.be/UxoX2faIgDQ?t=4939

.c0 { color: blue; }
.c1 { color: red; }
.c2 { font-size: 16px; }

// Generated Component (Pre-Optimized)
const styles = {
blue: {color: 'c0'},
default: {color: 'c1', fontSize: 'c2'},
};

function MyComponent(props) {
return (
<span className={styles(
'default',
props.isBlue && 'blue',
)}>
Hello World!
</span>
);
}

這個例子展示了 CSS 怎樣原子化，它還展示了如何使用 props 設定 span 的顔色，但這段代碼還能進一步優化。

// The styles block is no longer needed
function MyComponent(props) {
return (
<span className={styles(
(props.isBlue ? 'c0 ' : 'c1 ') + 'c2 '
)}>
Hello World!
</span>
);
}

這些東西非常有趣，我期待能盡快看到他們釋出這個庫。

資料驅動的 JavaScript

想讓頁面看上去更快、互動更迅速嗎？Ashley Watkins 也在思考這個問題。她提醒了我，可以考慮用調整資料擷取的方法來改善使用者體驗。我本就對 Relay 感興趣，聽了她的演講就更躍躍欲試。

分段代碼分割

Facebook 一直在設法加快 FMP 的速度。他們的一種方法是“分段代碼分割”。

使用這種方法時，你可以一次下載下傳并分段傳遞。拿 Facebook 文章來說可以分為三段。

載入中
顯示
分析工具

每個階段都可以有自己的代碼擷取和渲染過程。FMP 所需的所有資料都可以在加載階段擷取代碼的時候同時擷取。

應該關注首次有效渲染的時間

為了盡可能優化使用者體驗，你應該關注的是首次有效渲染（FMP）[5] 所需的時間，其實這就是主要内容顯示在頁面上所需的時間。有許多名額可供參考以縮短加載時間，但 FMP 是非常關鍵的一個。

你可以在 Relay 中使用 GraphQL 進行流式查詢。你可以将某些資料标記為關鍵資料，而将其他資料标記為非關鍵資料。然後你可以先從伺服器擷取最重要的内容，并在擷取其餘資料的同時開始顯示内容，這樣你就可以在内容到達時立即開始渲染。

資料驅動的代碼分割

這個驚到我了。Relay 太強了，無可争議。Relay 有一項新功能，可讓你擴充查詢以檢視渲染特定資料類型時所需的元件代碼。你可以将代碼視為資料。當伺服器解析你的 GraphQL 查詢時，它可以讓用戶端知道後者将需要下載下傳哪些元件代碼，進而可以更快地擷取它們。

Ashley 的演講太棒了，她承諾說這些僅僅是個開始。我還沒使用過 Relay，但我迫不及待想開始了，相信你也會這麼做（尤其當你了解了它更多的能耐後）。

解決全球的饑餓問題

大會第一天主要談的是技術話題，讨論生态系統即将到來的衆多功能如何改善使用者體驗。

Tania Papazafeiropoulou 則一轉話題，開始探讨全球範圍的饑荒問題，以及她正在研究的一種很酷的産品 OLIO。它可以幫助人們分享食物，而不是浪費食物，而且它是由 React 打造的。

這個演講并沒有大肆宣傳 React 的新功能，但它讓人們更加認識到 React 的力量根源所在。React（和 React Native）使 Tania 的團隊能夠快速建構産品，并開始對社會産生積極的影響。

改進 REST 的體驗和安全性

RESTful API 并不是一個新的熱門概念。它們是在 2000 年正式定義的，自從它被定義以來已經取得了顯著的成績。話雖如此，REST 确實有一些值得挑戰的問題。

Facebook 用 GraphQL 回應了這些挑戰。GraphQL 為我們提供了對資料的可了解的定義。它可以讓客戶隻擷取所需的内容。這樣渲染速度就能顯著加快，因為你不必下載下傳太多資料。

Tejas Kumar 很好地總結了新舊技術的差異：

https://youtu.be/UxoX2faIgDQ?t=9586

REST

❌沒有規範的資料格式

❌猜謎遊戲（不允許的請求會以 400、401 還是 404 響應呢？）

❌無意義的對話

❌無合約協定

GRAPHQL

✅規範的資料格式

✅沒有猜謎遊戲

✅有意義的讨論（影響使用者的事物）

✅強有力的合約協定

許多人都喜歡 GraphQL，但有時它不是 API 的選擇。Tejas 和他的團隊開發了一種工具，可以消除 REST 的一些陷阱 [6]。它包括 Swagger 的代碼生成和 OpenAPI 規範。

React 的引擎（建構自定義渲染器）

如果你曾經示範過以前編寫過的代碼，肯定知道渲染器經常會出錯。于是 Sophie Alpert 就在演講中教我們怎樣建構一個 React 渲染器。

我不覺得我是 React 專家（目前不是）。我從沒看過 React 代碼庫，覺得那肯定很難吧。但随着我繼續學習和掌握 React，最終還是到了研究代碼庫的時候。不過看 Sophie 在 React Conf 講台上現場建構一個自定義渲染器，似乎也沒那麼難嘛。

本地化（一件很重要的事）

我們這些母語是英語的開發人員做産品時往往不會首先考慮本地化問題。值得慶幸的是，還好我意識到了這一點，以後會更認真地對待它。

我們總覺得使用者和我們一樣，是以沒那麼關心本地化的問題。可現實中使用者并不是都和你一樣的！這就是為什麼我們需要使用者測試、獲得使用者回報，并做出更加包容的産品，适應所有的使用者類别。

去年 Nat Alison 提出了一個問題：“React 有其他語言版本嗎？”當時的答案是否定的。

為什麼這個問題如此重要？Nat 總結得很好。如果隻有說英語的人才能使用 React，那麼會有多少人沒法使用這些工具來開發出令人贊歎的産品？如果隻讓說英語的人來塑造我們的數字世界，我們的損失得有多大？世界上隻有 20％的人口英語。如果我們不幫助其他語種的人們使用 React，将來隻會自讨苦吃！

Nat 和幾千同行在過去一年中取得了難以置信的成就。但還有更多工作要做，如果你會兩種語言，可以為此做出貢獻。

https://isreacttranslatedyet.com/

無障礙馬拉松

就像本地化一樣，可通路性 / 無障礙功能可能也不是輕松的活。開發無障礙功能時，你需要改變思考方式。你必須考慮更多的閱聽人，考慮可能與你不同的人群。有時候這很困難，但我們都能做到。

跑馬拉松是另一個可能很難做到的例子。根據 RunRepeat 的資料，2018 年有 1,298,725 人完成了馬拉松比賽。這并不是他們天生就能做到的事情，他們是一步一個腳印，最終實作了自己的目标。

我們面對無障礙功能也要有這樣的精神。一步步來，就不會覺得那麼不堪重負了。React Conf 吸引我的其中一點就是從新的角度學習軟體開發和了解世界。Brittany Feenstra 的演講又一次擴大了我的視野，讓我更深入地思考無障礙功能。

我不會在一夜之間完成無障礙馬拉松，但可以每天一點點向前推進。值得慶幸的是，在此過程中有很多好工具可用 7。

你不需要 Redux（對嗎？）

在 2019 年，管理 React 狀态有許多方法可用（甚至包括 easy-peasy）：

https://reactjs.org/docs/react-component.html#setstate https://reactjs.org/docs/context.html https://reactjs.org/docs/hooks-intro.html https://github.com/reduxjs/redux https://github.com/jamiebuilds/unstated https://github.com/mobxjs/mobx https://www.apollographql.com/docs/react/data/local-state/ https://easy-peasy-v3.now.sh/

選擇困難症又犯了。然而哪個選項才是正确的取決于你的情況。請記住，開發人員體驗是服務使用者體驗的。是以，我喜歡用盡量簡單，能随我的原始決策改變而變化的方式來管理狀态。

很高興看到 React 現在内置了很多選項。你可以使用 Context 和 Hooks 做很多事情，而無需其他依賴項。

為了快速行動并完成目标，你必須願意放棄以前完成的工作。要讓你的産品與衆不同，你需要愛上重構并走出舒适區。我認為管理 React 狀态的許多選項都反映了這一點。有些選項需要很多樣闆，有些則不需要。有些是建構好的，有些不是。跟着感覺走，将來随時按需調整。

夢回 1999

這場演講的标題就很吸引人 [9]。1999 年的程式設計是什麼樣的？那時我才九歲。有些人九歲就開始寫代碼，可惜我不是其中之一。

這場演講也是必看的。Lee Byron 送上了一段精心打造的内容。他帶我們回到了 PHP 和 LAMP 堆棧成為 Web 開發工具的年代。他向年輕人講述了 Facebook 開發 React、GraphQL 和 Relay 等工具之前走過的那些曆程。對于老一輩來說，那是值得懷念的時光。

我一直都很尊重 Facebook 所做的工程工作，而這場演講捋清了背後的成因。使用 React 就好像是一種特權，現在我知道這種感覺來自哪裡了，正是 Lee 這樣的人為社群所做的一切激勵着我們前進。

連開發工具都和 UX 相關

第二天的第一場演講是 Brian Vaughn 做的。用 React 建構内容的開發人員大概都用過 React Dev Tools。它們幫我擺脫了許多我自己制造出來的混亂局面。

React Dev Tools 得到了全面的重寫，為我們帶來：

更好的性能

新的 API 支援

新的 UX 功能

看看，連開發工具都專注于提供出色的 UX！

一項讓我印象深刻的改進是幫助團隊浏覽之前不熟悉的項目。我們沒接觸過的代碼看起來肯定很陌生，但我們也都知道哪怕是自己寫的代碼時間久了也快不認識了。現在，我們可以看到 props 如何流過元件，可以過濾元件樹，可以深入檢查元件以及如何将 hook 與 dev tool 一起使用。另一個好東西是 suspense 開關。這個功能看起來很簡單，但價值不可估量。

再加上共享配置檔案的改進，新的開發工具讓我們更容易找出渲染事物的起源。第三方也有類似的工具 [10]，但現在我們可以直接在開發工具中了解渲染背後的内容了。

其他内容還有不少，建議大家自行探索 [11]。

可 Suspense 的資料（Relay 太棒了）

我在一個小項目裡一直在使用 GraphQL，而且非常喜歡它。接下來我得試試 Relay，看看它們的組合有怎樣的能量。

React Suspense 的宗旨是讓我們能夠先顯示某些 UI，而無需等待所有 UI 準備就緒。

來看一個元件的基本示例，該元件在擷取資料時顯示加載狀态（使用 Suspense）：

const Composer = (props) => {
const data = useQuery(graphql`
query ComposerQuery {
me {
photo {
uri
}
}
}
`, variables);

return (
<div>
<img src={data.me.photo.uri} />
</div>
);
}

const Home = (props) => (
<Suspense fallback={<Placeholder />}>
<Composer />
</Suspense>
);

在此示例中，我們有一個 Composer 元件，該元件可擷取個人資料圖檔的 URI，然後顯示它。你可以看到，在 Home 元件中我們将 Composer 包裝在一個 Suspense 塊中。然後在加載資料時将渲染 Placeholder。這種模式可以被視為“渲染時擷取”。這種模式的加載順序如下：

如你所見，這使我們能輕松處理資料加載。我們可以回退到 placeholder 或 spinner 等加載元件來提供更好的使用者體驗。

上面的模式提供了很多好處和靈活性。但 Facebook 團隊認為，想要找出元件所需的資料時沒必要先渲染元件。為了解決這個問題，他們開始使用一種稱為“擷取時渲染”的模式。

為了實作“擷取時渲染”，Facebook 團隊将 useQuery 分解為兩部分，分别是 preloadQuery 和 usePreloadedQuery。這到底是什麼意思呢？

preloadQuery

該 API 将擷取資料并為結果提供參考，但它沒有提供實際資料。

你将在顯示新使用者界面的那個事件處理程式中調用此 API。例如，如果使用者單擊連結，觸發導航到新頁面的動作，則我們處理單擊的事件處理程式将使用 preloadQuery。另一個例子是将滑鼠懸停在某處以打開工具提示。onHover 事件處理程式将調用 preloadQuery。

usePreloadedQuery

該 API 接受 preloadQuery 調用的結果。實際上它本身不會擷取任何資料。它檢視 preloadQuery 的目前狀态。如果準備就緒，它将顯示結果；如果尚未準備就緒，它将暫停；如果查詢失敗，則可能引發錯誤。

無論發生什麼情況，usePreloadedQuery 都不會觸發新的擷取，這使其高效且可預測。

使用這兩個 API 代替 useQuery 後，加載順序如下所示：

強烈建議大家聽聽 Joe Savona 的演講。他總結得更好更深入。這是我最喜歡的演講之一，因為我對這種模式所帶來的可能性感到非常激動，并且迫不及待地想嘗試一下。

如小說般的 React

Jenn Creighton 發表了我最喜歡的哲學演講。她從事創意寫作工作。創意寫作一直是我的最愛。像 Jenn 一樣，我曾經幻想成為作家。她在演講中解釋了一個概念，這個概念以一種有趣（且出乎意料）的方式轉化為編碼。

展示，不要講述

我們看一下傳達相同含義的兩種方法（Jenn 講的例子）。

她累了。

她的步伐愈加艱難，一點點挪向床邊，身體也越來越沉重了，最後一頭紮進了被褥裡。

表達她累壞了，同樣的意思，哪種表達更有力量？答案自不必說。我們軟體工程師經常會陷入講述的陷阱裡。我們抽象、抽象、抽象，直到抽幹一切。

大多數情況下，我會盡力避免代碼重複。這條原則自有其意義，但就像寫作不能循規蹈矩一樣，有時我們也需要打破軟體開發的規則。比較一下兩段結果相同的不同代碼。

const Nav = ({ links }) => (
<nav>
{
links.map(link => (
<Link to={link.to}>{link.name}</Link>
))
}
</nav>
);

const Header = () => {
const links = [
{ name: 'Home', to: '/home' },
{ name: 'Settings', to: '/settings' },
];

return (
<>
<Nav links={links} />
</>
);
}

這看起來很好用，但如果我們想添加一個導航項該怎麼辦？例如一個登入按鈕。

const links = [
{ name: 'Home', to: '/home' },
{ name: 'Settings', to: '/settings' },
{ name: 'Login', to: '??' },
];
我們的 Nav 元件無法處理這種情況。我們可以很容易地實作一種處理它的方法，但這也很容易失控。我們可以重構 Nav 元件，變成像這樣：
const Nav = ({ links }) => (
<nav>
{
links.map(link => {
return link.to
? <Link to={link.to}>{link.name}</Link>
: <a onClck={link.onClick}>{link.name}</Link>
})
}
</nav>
);

這樣也行，但我們得涵蓋多少邊緣情況？最後 Nav 元件的推理會不會太過複雜？我們可以用另一種方式重寫 Header 元件。

const Header = () => {
const links = [
{ name: 'Home', to: '/home' },
{ name: 'Settings', to: '/settings' },
{ name: 'Login', to: '??' },
];

return (
<nav>
<Link to="/home">Home</link>
<Link to="/settings">Settings</link>
<a onClick={onSelectLogin}>Login</a>
<nav/>
);
}

我簡化了 Jenn 演講中的例子，但應該足夠說明問題了。第二個 Header 元件更容易推理。盡管我們現在可能會重複一點東西，但這并不會有多大壞處。如果我們想将 Icon 元件添加到其中一個連結中，則不必再處理 Nav 元件中的所有極端情況，隻需将其添加到所需位置即可。Jenn 還引用了 Neil Gaiman 的妙語，我得給大家分享一下。

請記住，為了做到完美，你遲早要放開當下的執念，然後繼續寫下一篇。

在建構心理健康寫作平台 Wrabit 的時候，我一直在追求完美。有時候這讓我覺得自己不像一個開發人員，有時候讓我感到疲倦。最後我就隻去關注那些自己可以了解、可以傳遞、将來随時可以重構的内容了。

正如 Jenn 所說，重構并非失敗。

UX 驅動的流體動畫

我做過的動畫不算太多。我設想的未來中，我将從 Dribbble（動畫之類的東西）中獲得出色的 UI 設計，并用在實踐中。動畫絕對是優秀設計的重點所在，但我們玩動畫時也得牢記使用者體驗。

Alex Holachek 的演講也拓寬了我的思路。我喜歡 UI 互動，它們讓我的内心感到溫暖舒适。但我并沒有考慮到所有使用者，這是我的錯。

對于使用諾基亞 6 的使用者來說，精美的動畫該怎麼展示出來呢？畢竟大多數人都會選擇購買中端機型甚至低端機型，而不是新款 iPhone。

Alex 的演講讓我更多去考慮大衆的水準。平均的裝置性能，平均的資料帶寬，等等。為大衆打造的産品，高端使用者是不會覺得不滿的。

另外，event.preventDefault() 會對滾動産生不良影響。

真實的疊代體驗

今年的講座内容千姿百态。Luca Demasco 與 Zach Rispoli 合作開發了 Wick 編輯器 [12]，向我們展示了疊代的過程，很新奇的話題。

Wick 編輯器是一個免費的開源工具，可用于建立遊戲、動畫以及你能想到的任何東西。當 Luca 展示目前版本時，UI 确實給我留下了深刻的印象，看起來很直覺，并且有很多功能。但一開始并不是這樣的。

Luca 和朋友通過不斷的疊代才達到了今天的狀态。他們也不隻是為了疊代而疊代。他們将 Wick 帶入了許多環境（學校、圖書館等），并在許多類型的使用者（初學者、中級、年輕人、老人）面前展示了界面。他們采取了擷取，保留，擴張（Laser-Focused Approach）的方法，并收集了大量回報，才讓 Wick 有了今天的成果。

在我考慮如何疊代自己的産品時，這種真實的過程給了我啟發。如何快速啟動項目并有目的地疊代？我沒有那種體驗，是以有時候會缺少信心，但我很希望能享受這個過程。看到像 Luca 這樣的人分享經驗使我備受鼓舞，我感謝大會上所有人的真誠分享