[譯] React 的今天和明天（圖文版） —— 第一部分
早上好。大家好，歡迎來到 React 大會。今天來到這裡我感到非常激動。我非常激動本週可以給你們做開場演講。
我是 Sophie Alpert，個人主頁是 sophiebits。我是 Facebook 的 React 核心小組的經理。
React 的今天
你們正在使用的 React 做的很好。我們在 npm 的下載量一年內增加了 70%。 React Dev Tools 在 Chrome 開發者工具擴充套件程式的安裝量達到了 125 萬。
這是使用 React 的公司列表。此時此刻，這個列表已經非常長了，我們很難說清每年使用 React 的公司的變化。
我們來看另一組資料，我們來看看 Google 趨勢, 它可以反映出網路搜尋的流量。可以看到，React 的搜尋量一直在增加。 希望這個資料表示有更多的人在使用 React，而不是 React 變得更加令人困惑了。（笑聲）
嗯，為了做比較，我們比較了 jQuery 的搜尋量，我們的搜尋量剛剛在歷史上首次超越了 jQuery。（歡呼和掌聲）但這也表明，我們仍然有很多成長的空間。
我在寫這個演講時被耽擱了一會兒。 因為我比較好奇 React 還比什麼更流行。 哎呀。（笑聲）當我開了個玩笑。嗯，我發現 React 比可再生能源更流行。（笑聲）
React 也比橙汁更流行。（笑聲）想想橙汁是多麼常用啊，是吧。
而且 React 比可再生能源和橙汁加在一起更流行。所以我認為我們有理由感到非常自豪。
React 的使命
但是除了這些數字，我今天真正想要講的是 React 的使命。呃，自從 2013 年 React 釋出以來，我們首要的目標和主要的使命就是：讓開發者更容易地構建好的 UI。
所以當我們想要增加新的特性時，我們通常都是要經過深思熟慮。當我們決定是否增加新的 API 時，我們需要考慮非常多的事情。如果增加新的 API 能夠讓你做到一些以前做不到的事情；如果可以顯著簡化元件裡的程式碼和類庫，讓你的工作量減小，使用者下載更少的程式碼，那新增 API 就是有價值的。或者如果新增 API 能夠幫助我們做到程式碼分割的最佳實踐，如果能夠更容易地將你 app 裡面的程式碼分割成多個包，我們希望你的 app 最終可以執行更快。這也是我們兩週之前宣佈增加像 React.lazy 這樣的API 的原因。 你們可能已經注意到了這個 API。 但想想 React 的使命，讓開發者更容易地構建好的 UI。
我們有很多方法來實現這個目標。 其中一點是我們嘗試簡化複雜的東西。如果你看了 Dan Abramov 在冰島的 JS Conf 上的演講，你可以搶先看到 "Suspense", "Suspense" 是我們用來顯著 簡化 app 中獲取資料請求、程式碼分割和非同步資料依賴的問題。
另外一個我們嘗試去提升 React 的方式就是提升效能。如果你的 app 執行速度更快，你的使用者就會更原意使用它。相反的，如果你的 app 反應很慢，速度卡頓，那你的使用者肯定不會有很好的體驗。因此我們嘗試讓 React 本身執行的更快，如果 React 開箱就很快，那麼你們就會省下很多優化你自己程式碼的時間。
最近和提升效能有關的內容，Dan 也在冰島的 JS Conf 上提到了，我們稱其為 "Time Slicing"。"Time Slicing" 可以確保你 app 裡面最重要的渲染會最先執行，解除主執行緒的阻塞，並且能讓你的 app 執行地更快速。
第三種方式是使用開發者工具幫助你 debug ，進而更瞭解你的 app。一開始，React 就包含了對開發者友好的警告來幫助開發者指出問題，以防開發者沒有注意到這些問題。
而且我們的 React Dev Tools 擴充套件程式能夠讓你檢查並且 debug 你的元件樹。 在 React 16.5 版本，我們引入了一個叫 Profiler 的新特性。它是第二個 ... （我不知道這個遙控器出了什麼問題）... 圖上的第二個標籤欄就是 profiler 標籤欄， 它能夠幫助我們瞭解到你的 app 中到底發生了什麼，然後更好地優化它。
所以 Suspense, Time Slicing 和 Profiler 這三個新特性是我們去年一直在做的事情。 我們真的想多說一些關於這三個特性的內容。但是這些並不是我今天在這裡想要講的。大家可以等到明天，Andrew 和 Brian 會在明天早上給大家帶來關於這個內容的演講。
React 還存在什麼糟糕的地方
現在我想退一步，我們來關注一些其他的問題。我想問的是，現在 React 還有什麼糟糕的地方。我總結出了三個問題，想在這裡和大家討論。
邏輯複用
第一個問題就是多元件間的邏輯複用問題。
在 React 中我們主要使用元件來構建我們的應用，元件主要有兩種主要的模式來複用程式碼：它們是高階元件（higher-order）和渲染屬性（render props)。
這兩種模式對於某些場景來說是很好的，但是它們也造成了一個極大的缺點。在更加複雜的場景中，你必須將他們抽離出來去重構你的 app。這會導致一個問題，我稱之為”包裝地獄“（wrapper hell）。
嗯，我們經常會看到像這樣的元件樹。（尖叫和笑聲）而且這種巢狀會造成跟蹤 app 資料流的困難。如果能夠複用這類有狀態的邏輯，而不需要修改元件的層級，那肯定是很好的方法，對吧。
龐大的元件
第二個我想講的問題是龐大的元件，它的邏輯雜亂無章。 我們來看看一個上千行程式碼的 React 元件，我們會發現邏輯分散到了許多不同的生命週期函式中，這樣非常難以跟蹤。
我們來看一個例子。這裡有一個 class 元件，在它的 did mount 方法，它做了幾件事：它訂閱了一個數據儲存中，然後傳送了一個網路請求，最後開啟了一個定時器。
那麼，如果我們來看元件的 will unmount 方法，我們會看到基本完全相反的程式碼：首先需要取消儲存的訂閱，然後取消網路請求，最後停止定時器。
當我們要實現元件的 did update 方法, 裡面的邏輯會更加的 tricky。因為你需要比較新舊的屬性，然後再一次重複和其他生命週期函式內部相同的任務邏輯。
呃，在這個例子裡，每個請求都只有一行，所以說這個例子實際上比你平時看到的元件要簡單的多。在真實元件中，邏輯往往會更加錯綜複雜，因為每個獨立的任務分散到了 不同的生命週期函式中，這樣會造成困難，舉個例子，當你 unmounting 元件時，你可能會忘記清除資源。這非常難以從程式碼中找到問題。
令人困惑的 Class
第三個糟糕的事情是 class。理解 JavaScript 裡的 classes 會相當 tricky，而且為了能夠使用 state 和生命週期，我們要求你們使用 class 元件才能做到。
如果你用過 function 元件，並且將其轉為了 class 元件，增加了一些 state，你就會知道需要有大量的樣本檔案，其作用僅僅是用來定義一個 class 元件。大多數初學者和很多有經驗的開發者也都跟我們抱怨過在 class 裡面的繫結和轉化工作相當令人困惑。 我們有必要來考慮這個問題。
而且我們經常聽說大家並不是非常清楚什麼時候使用 function 元件，有一部分原因是他們總會擔心早晚需要將這個元件轉化為 class 元件。所以你們可能會困惑， 我現在是否應該這麼做？我不知道。
所以我說 class 對於人類來說是很難的，但是不僅對於人類而言是這樣，我也斷言 class 對於機器而言也是很難的。
如果你看過壓縮後的元件檔案，可以看到所有的方法名沒有被壓縮。而且如果你有一個完全沒有使用的方法，它也沒有被剔除出去。這是因為在編譯時很難準確判斷方法是否被使用。
我們還發現 class 使得可靠的熱載入變得困難。最後當我們設計一個優化的編譯器原型來提升 React 元件效能時，我們發現 class 元件的一些模式使得編譯器優化變得更加困難。
總結
所以，我們現在有三個問題：邏輯複用、龐大的元件和 class。邏輯複用的問題會導致你經常遇到“包裝地獄“。龐大元件的原因是由於邏輯分散到了不同的生命週期中。而令人困惑的 class 無論對於人類還是機器來說都是個難題。
我們認為我們有了一個能夠解決以上三個問題的解決方案。我們特別想把這個方案分享給大家。請允許我請出 Dan Abramov 為我們帶來接下來的演講。