[譯] React 的今天和明天(圖文版) —— 第一部分

清秋發表於2018-11-12

2018年 11 月 30 日更新,第二部分已經更新:[譯] React 的今天和明天(圖文版) —— 第二部分 。前兩部分中英雙語字幕視訊已經發布:【React Conf 2018】React 的今天和明天中英文雙字幕

React 的今天和明天 —— 第一部分

2018-11-08 4 20 29

早上好。大家好,歡迎來到 React 大會。今天來到這裡我感到非常激動。我非常高興可以給你們做開場演講。

我是 Sophie Alpert,個人主頁是 sophiebits.com。我是 Facebook 的 React 核心小組的開發經理。

2018-11-08 4 20 59

React 的今天

你們正在使用的 React 做的很好。我們在 npm 的下載量一年內增加了 70%。 React Dev Tools 在 Chrome 開發者工具擴充套件程式的安裝量達到了 125 萬。

2018-11-08 4 21 47

這是使用 React 的公司列表。此時此刻,這個列表已經非常長了,我們很難說清每年使用 React 的公司的變化。

2018-11-08 4 22 08

我們來看另一組資料,我們來看看 Google 趨勢, 它可以反映出網路搜尋的流量。可以看到,React 的搜尋量一直在增加。 希望這個資料表示有更多的人在使用 React,而不是 React 變得更加令人困惑了。(笑聲)

2018-11-08 4 22 28

嗯,為了做比較,我們比較了 jQuery 的搜尋量,我們的搜尋量剛剛在歷史上首次超越了 jQuery。(歡呼和掌聲)但這也表明,我們仍然有很多成長的空間。

2018-11-08 4 23 05

我在寫這個演講時被耽擱了一會兒。 因為我比較好奇 React 還比什麼更流行。 哎呀。(笑聲)當我開了個玩笑。嗯,我發現 React 比可再生能源(renewable energy)更流行。(笑聲)

2018-11-08 4 32 14

React 也比橙汁(orange juice)更流行。(笑聲)想想橙汁是多麼常用啊,是吧。

2018-11-08 4 32 32

而且 React 比可再生能源和橙汁加在一起更流行。所以我認為我們有理由感到非常自豪。

2018-11-08 4 32 56

React 的使命

但是除了這些數字,我今天真正想要講的是 React 的使命。呃,自從 2013 年 React 釋出以來,我們首要的目標和使命就是:讓開發者更容易地構建好的 UI。

2018-11-08 4 35 26

所以當我們想要增加新的特性時,我們通常都是要經過深思熟慮。當我們決定是否增加新的 API 時,我們需要考慮非常多的事情。如果增加新的 API 能夠讓你做到一些以前做不到的事情;如果可以顯著簡化元件裡的程式碼和類庫,讓你的工作量減小,使用者下載更少的程式碼,那新增 API 就是有價值的。或者如果新增 API 能夠幫助我們做到程式碼分割的最佳實踐,如果能夠更容易地將你 app 裡面的程式碼分割成多個包,我們希望你的 app 最終可以執行更快。這也是我們兩週之前宣佈增加像 React.lazy 這樣的API 的原因。 你們可能已經注意到了這個 API。

2018-11-08 4 52 47

但想想 React 的使命,讓開發者更容易地構建好的 UI。我們有很多方法來實現這個目標。 其中一點是我們嘗試簡化複雜的東西。如果你看了 Dan Abramov 在冰島的 JS Conf 上的演講,你可以搶先看到 "Suspense", "Suspense" 是我們用來顯著簡化 app 中獲取資料請求、程式碼分割和非同步資料依賴的問題。

2018-11-08 4 54 19

另外一個我們嘗試去提升 React 的方式就是提升效能。如果你的 app 執行速度更快,你的使用者就會更原意使用它。相反的,如果你的 app 反應很慢,速度卡頓,那你的使用者肯定不會有很好的體驗。因此我們嘗試讓 React 本身執行的更快,如果 React 開箱就很快,那麼你們就會省下很多優化你自己程式碼的時間。

2018-11-08 4 54 56

最近和提升效能有關的內容,Dan 也在冰島的 JS Conf 上提到了,我們稱其為 "Time Slicing"。"Time Slicing" 可以確保你 app 裡面最重要的渲染會最先執行,解除主執行緒的阻塞,並且能讓你的 app 執行地更快速。

2018-11-08 4 55 44

第三種方式是使用開發者工具幫助你 debug ,進而更瞭解你的 app。一開始,React 就包含了對開發者友好的警告來幫助開發者指出問題,以防開發者沒有注意到這些問題。

2018-11-08 4 56 24

而且我們的 React Dev Tools 擴充套件程式能夠讓你檢查並且 debug 你的元件樹。 在 React 16.5 版本,我們引入了一個叫 Profiler 的新特性。它是第二個 ... (我不知道這個遙控器出了什麼問題)... 圖上的第二個標籤欄就是 profiler 標籤欄, 它能夠幫助我們瞭解到你的 app 中到底發生了什麼,然後更好地優化它。

2018-11-08 4 57 03

所以 Suspense, Time Slicing 和 Profiler 這三個新特性是我們去年一直在做的事情。 我們真的想多說一些關於這三個特性的內容。但是這些並不是我今天在這裡想要講的。大家可以等到明天,Andrew 和 Brian 會在明天早上給大家帶來關於這個內容的演講。

2018-11-08 9 08 56

React 還存在什麼糟糕的地方

現在我想退一步,讓我們來關注一些其他的問題。我想問的是,現在 React 還有什麼糟糕的地方。我總結出了三個問題,想在這裡和大家討論。

2018-11-08 9 10 04

邏輯複用

第一個問題就是多元件間的邏輯複用問題。

2018-11-08 9 10 29

在 React 中我們主要使用元件來構建我們的應用,元件主要有兩種主要的模式來複用程式碼:它們是高階元件(higher-order components)和渲染屬性(render props)。

2018-11-08 9 11 44

這兩種模式對於某些場景來說是很好的,但是它們也造成了一個極大的缺點。在更加複雜的場景中,你必須將他們抽離出來去重構你的 app。這會導致一個問題,我稱之為”包裝地獄“(wrapper hell)。

2018-11-08 9 15 54

嗯,我們經常會看到像這樣的元件樹。(尖叫和笑聲)而且這種巢狀會造成跟蹤 app 資料流的困難。如果能夠複用這類有狀態的邏輯,而不需要修改元件的層級,那肯定是很好的方法,對吧。

龐大的元件

第二個我想講的問題是龐大的元件,它的邏輯雜亂無章。 我們來看看一個上千行程式碼的 React 元件,我們會發現邏輯分散到了許多不同的生命週期函式中,這樣非常難以跟蹤。

2018-11-08 9 19 58

我們來看一個例子。這裡有一個 class 元件,在它的 componentDidlMount 方法,它做了幾件事:它訂閱了一個資料儲存,然後傳送了一個網路請求,最後開啟了一個定時器。

2018-11-08 9 20 50

那麼,如果我們來看 componentWillUnmount 方法,我們會看到基本完全相反的程式碼:首先需要取消訂閱儲存,然後取消網路請求,最後停止定時器。

當我們要實現 componentDidUpdate 方法, 裡面的邏輯會更加的 tricky。因為你需要比較新舊的屬性,然後再一次重複和其他生命週期函式內部相同的任務邏輯。

呃,在這個例子裡,每個請求都只有一行,所以說這個例子實際上比你平時看到的元件要簡單的多。在真實元件中,邏輯往往會更加錯綜複雜,因為每個獨立的任務分散到了 不同的生命週期函式中,這樣會造成困難,舉個例子,當你 unmounting 元件時,你可能會忘記清除資源,這非常難以從程式碼中找到問題。

令人困惑的 Class

第三個糟糕的事情是 Class。理解 JavaScript 裡的 class 會相當 tricky,而且為了能夠使用 state 和生命週期,我們要求你們使用 class 元件才能做到。

2018-11-08 9 22 30

如果你用過 function 元件,並且將其轉為了 class 元件,並增加了一些 state,你就會知道這個過程需要有大量的樣板檔案,但是其作用僅僅是用來定義一個 class 元件。大多數初學者以及很多有經驗的開發者也都跟我們抱怨過在 class 裡面的繫結和轉化工作相當令人困惑。我們有必要來關注這個問題。

而且我們經常聽說大家並不是非常清楚什麼時候使用 function 元件,有一部分原因是他們總會擔心早晚需要將這個元件轉化為 class 元件。所以你們可能會困惑, 我現在是否應該這麼做?我不知道。

所以我說 class 對於人類來說是很難的,但是不僅僅對於人類而言是這樣,我認為 class 對於機器而言也是同樣很難。

2018-11-08 9 23 52

如果你看過壓縮後的元件檔案,可以看到所有的方法名沒有被壓縮。而且如果你有一個完全沒有被使用的方法,它也沒有被剔除出去。這是因為在編譯時很難準確判斷方法是否被使用。

我們還發現 class 使得可靠的熱載入變得困難。最後當我們設計一個優化的編譯器原型來提升 React 元件效能時,我們發現 class 元件的一些模式使得編譯器優化變得更加困難。

總結

所以,我們現在有三個問題:邏輯複用、龐大的元件和 Class。邏輯複用的問題會導致你經常遇到“包裝地獄”。龐大元件的原因是由於邏輯分散到了不同的生命週期中。而令人困惑的 class 無論對於人類還是機器來說都是個難題。

2018-11-08 9 22 30

我們認為我們有了一個能夠解決以上三個問題的解決方案。我們特別想把這個方案分享給大家。請允許我請出 Dan Abramov 為我們帶來接下來的演講。


傳送門


希望看本文視訊的同學,可以檢視我的這篇文章:React Conf 2018 專題 —— React Today and Tomorrow PART I 視訊中英雙語字幕,中英雙語字幕已經給大家準備好了。我們的 Demo Boy —— Dan Abramov 後面關於 React Hooks 的精彩演講正在翻譯中,歡迎有興趣的同學聯絡我一起翻譯,讓更多的小夥伴能夠更快看到 React Conf 2018 的精彩內容。

相關文章