React Conf 2017 不能錯過的大起底——Day 1！

時間 2019-11-17

標籤 react conf 不能錯過 day 欄目 React 简体版

原文原文鏈接

就在前不久，React Conf 2017 在加利福尼亞州的聖克拉拉萬豪酒店圓滿落幕，這已是第三屆 React 官方大會了。今年的大會怎麼樣，有哪些新東西，外刊君接下來將會給你們來個大起底，Day 1 大放送！javascript

ReactConf2017 應用

Fhinkmill 的工程師基於 React Native 開發一個應用——ReactConf2017。下載：iOS、Android。參會者能夠在應用上查看日程安排，會議地點，獲取參會路線等等。參會體驗++。html

主題演講（keynote）

一些事實

React Dev Tools 的安裝量超過 50w；
Facebook 自家的 App 已經有成百上千的 Screen 使用了 React Native；Facebook 主應用使用仍是React + Hybrid；Instagram 已沒法指出 Native 和 React Native 上體驗的差異。
Facebook 的工程師沒有打算使用 React Native 重寫整個Facebook主應用；

React Native 在 Facebook 不斷地推動

爲了在 Facebook 主應用中逐漸地引入 React Native，對以下三個方面進行了優化。java

性能

文件壓縮減小體積天然不用說了，React Native 進一步衡量了啓動渲染各個環節消耗的時間，儘可能縮短或者並行處理這些環節。react

通用

針對 iOS和Android的差別，提供通用的 API。git

開發者體驗

Facebook 主應用上千人維護，幾分鐘才能編譯一次，React Native 作到了即改即現，優化與navigation的集成，實現了添加新的 page，也無需從新編譯整個應用。github

React Native 進過不斷的打磨、提高和使用，它的 Scope 也在一步步發生變化。web

Webview Conversions: 有更好的交互體驗；
High Iteraction Views：需求不斷變化，快速迭代的功能；
Other Full-Sreen Views：全屏功能的 View；
Cross-App Views：跨 App 功能界面共享。

React 端到端性能（React Fiber）

目前如何合理安排 React 計算渲染更新是優先級很高的核心工程。React 團隊設計出thread、worker、build 優先級等等，最終得到了一個可行的模型，從新肯定如何繪製UI——即 React Fiber。React Fiber 不是一個新的項目，是 React 的新架構，將在 React 16 發佈。github.com/acdlite/rea… facebook.com 上已經用上了 React Fiber。你們能夠下載 react@next react-dom@next 試用。算法

看動畫識 Fiber

Fiber 能夠提高複雜React 應用的可響應性和性能。Fiber 便是React新的調度算法（reconciliation algorithm）。編程

react 即 reconsiler（調度者），react-dom則是 renderer。調度者一直都是又 React 自己決定，而 renderer 則能夠由社區控制和貢獻。 redux

那新的調度算法是如何優化可響應性和性能的呢。

每次有 state 的變化 React 從新計算，若是計算量過大，瀏覽器主線程來不及作其餘的事情，好比 rerender 或者 layout，那例如動畫就會出現卡頓現象。

React 制定了一種名爲 Fiber 的數據結構，加上新的算法，使得大量的計算能夠被拆解，異步化，瀏覽器主線程得以釋放，保證了渲染的幀率。從而提升響應性。

React 將更新分爲了兩個時期：

render/reconciliation

可打斷，React 在 workingProgressTree 上覆用 current 上的 Fiber 數據結構來一步地（經過requestIdleCallback）來構建新的 tree，標記處須要更新的節點，放入隊列中。

commit

不可打斷。在第二階段，React 將其全部的變動一次性更新到DOM上。

除此以外，還有更多的優化細節，能夠參看 Lin Clark 的演講視頻。

更詳細的解讀，能夠看到演講視頻或者知乎專欄進擊的React的解讀文章：React Fiber是什麼

Next.js

React SSR（Server Side Render）框架。做者 Guillermo Rauch （socket.io 做者）甚至使用 Next.js 重寫了 hacker news。

Guillermo Rauch 分享了不少 Next.js 的實現細節和設計哲學，更多能夠參看分享視頻。

外刊君：不敢想象，經過 Next.js 這個框架，咱們編寫熟悉的 React 代碼，以最快的速度完成一個具有 SSR 能力的站點，無需一行配置。

React + ES.next = ♥

又一個從 Backbone 切換到 React 的例子 :)。Ben Ilegbodu 給咱們介紹如何結合 ECMAScript 新的特性，寫出更讚的 React 代碼！

這五個特性你們都認識吧！

Destructuring（解構負值）

從對象中解構出屬性，甚至負值給新的變量：

從對象參數中解構：

Spread operator

兩種 Spread operator 的實戰用法：

代替 Object.asigin 和 Array.prototype.concat，實現不變數據：

代替 Function.prototype.apply 展開數組做爲參數：

Arrow Funciton

結合上上面的特性，咱們甚至能夠這麼編寫 JS：

const MyComponent = ({children, style}) => {
    <div style={style}>{children}</div>
}複製代碼

Promise

Promise 就略去不表了，不熟悉的童鞋，再去看看視頻複習複習吧。演講者提到了 Pormise.all方法，同事也還有相似的 Promise.race、Promise.resolve、Promise.reject 等等，能夠學習學習。

Async Function

使用 Async/Await 咱們真的可使用同步的代碼書寫異步的實現了。

注意這裏的fatch返回的是一個 Promise 對象，fetch 的操做實際上是異步的。注意須要使用 try catch 來捕獲 Promise 對象 reject 的錯誤！

Redux VS MobX

兩個技術方案的比較必須先了解每一個的優點和權衡，在造成本身的理想簡介。看看 Preethi Kasireddy 是怎麼說的。

Redux 是 Flux 模型的一種衍生，但有三點主要的不一樣：

單一 Store;
使用pure function代替dispatcher
store/state 是不可變數據

Preethi Kasireddy 用了一個頗有意思的比喻。能夠把 Mobx 當作一個 spreadsheet，有一類是純數據cell，有一類是經過純數據的cell加公式計算出來的cell。純數據的cell上就像加了 obserable，數據cell變化了也會致使另一種cell中數據的變化。

上面是 Redux 和 Mobx 內部技術結構的具體比較：

Redux 的 Store 是單一的，而 Mobx 是分散的，能夠按照領域來組織；
Redux 的數據是純對象，而 Mobx 是一系列的 Observable 數據；
Redux 依賴的是不可變數據結構，而 Mobx 數據時可變的；
Redux 的狀態沒有花頭，都是普通對象，而 Mobx 的狀態其實是嵌套的，由於是一系列 Observable 數據的依賴樹。

學習曲線比較，Mobx 比價容易，OO編程，不過有一些 Magic；而 Redux 則帶着 FP 的思想，不過 Redux 沒有黑魔法，reasonable。

妹子認爲 Redux 學習曲線比較陡峭，尤爲是應用複雜之後，如何規劃 Store 是個問題。

誰更容易快速上手？

開發工具：

在可肯定性、調試方面 Mobx 不及 Redux。模塊化開發角度來講，Mobx 略勝。

在擴展性、可維護性、社區 Redux 都更勝一籌。

setState vs Redux vs Mobx

setState 做爲 React 的 API，一切都是從這裏開始，咱們有必要學習 React 的最基本的用法。可是涉及到在多個孤立節點共享狀態時，只用 React 就有些力不從心了。這時候，Redux 和 Mobx 就能夠派上場了。

Preethi 認爲 Mobx 適合作一些簡單的應用，原型實驗，適合小的團隊使用。Mobx 的優勢是響應狀態的變化。

而 Redux 適合複雜的應用，大團隊，需求變化多。它的有點是響應動做和事件。

不過最終該選什麼呢？Preethi 的回答是：

pick tool that makes you a happy developer.

更多的細節內容，可參看演講視頻，或者知乎專欄 pure render 的詳細介紹：MobX vs Redux: Comparing the Opposing Paradigms - React Conf 2017 紀要

Type Systems Will Make You a Better JavaScript Developer

首先先複習一下 JavaScript 的類型系統：

一般，會存在一些意想不到，難於定位的錯誤。

使用 lint 工具能夠避免一部分錯誤。經過 runtime 的類型檢查也能夠作到，可是有大量的檢查代碼。

React 中的 propTypes 一樣也起到了類型檢查的做用，不過是在 runtime，相對來說，更好用一些。

今天的主教出場了 flow，靜態 JavaScript 類型檢查工具。

集中類型檢查方式的比較：

接下來是 Jared Forsyth 一些 flow 使用心得，即就算有了 Static Type Checking 也沒法處理的部分——即那些代碼中暗含的約定。最後 Jared 總結道：

閃電分享#1

Moving Fast with Nuclide and Flow

Nuclide 是 Facebook 工具團隊開發的 IDE，基於 Atom。Andres Suarez 爲了我介紹 Nuclide 結合 Flow 的各類特性，好比自動補全、Type Checking、跳轉到定義、代碼大綱等等功能。有興趣的童鞋能夠動手使用起來。

AWS Lambda + AWS Gateway + React = AWEsome

編寫一個函數，上傳到 AWS Lambda，Lambda 就能夠執行這個函數來幫你響應 HTTP 請求，文件上傳事件等等。服務器的監控、複雜均衡等等都不用關心。這是一種"serverless" 服務。目前支持 Node.js、Python 和 Java。

因而，咱們能夠這來構建項目：

因而做爲工程師，咱們就能夠很歡快地編寫 React 和 JavaScript 函數來開發咱們的應用了。

React to Code

Merrick Christensen 分享了本身的項目，react-sourcerer，使用 JSX 的語法來描述 JavaScript AST 的匹配規則。

The Road to Styled Components

一個很是有趣的項目，提供了一種耳目一新的方式來構建一個帶樣式的組件：

外刊君：這其實用到了 ES6 Template literals 特性。

Title、Wrapper 組件的用法與 React 組件無異：

甚至還支持繼承、主題等特性。

Building Applications for a Studio in the Cloud at Netflix

Feather Knee 來 React Conf 2017 走了一遭，宣佈我大 Netflix 去年11月份也開始用 React啦，而後分享了一下他們的 React 技術棧。

React Native in the "Brown Field"

Leland Richardson 把整個 React Native 到已有項目中稱爲「Brown Field」。Leland 帶來了 React Native 到 Airbnb 的整合實戰經驗。

Airbnb 2016年3月開始實驗性地使用 React Native；
7月，Airbnb 第一個 React Native 開發的功能上線；
11月，Aibnb Trips 平臺創建，iOS/Android客戶端的大量功能都是使用 React Native 開發的。

適合的事情交給適合的語言和平臺去作，React Native 自己就包含C/C++ Objective-C，Java，JavaScript 這四種語言的代碼。

來分析哪些是 Native 哪些是 JavaScript：

YOGA Native 佈局類庫，Native 的；
React，純 JavaScript 類庫；
大部分核心組件都是Native實現，暴露JavaScript接口；

歸類下來，一部分是實現需求的代碼（Product Code），另一部分就是基礎設施代碼，其目的是使得Product Code更容易編寫。

但對於開發 Brown Field 來講，是另一種景象，隨着 React Native 的不斷引入，Product code 更多地由 JavaScript 完成，基礎設施代碼也逐漸暴露出 JavaScript API。

在Brown Field和Green Field都存在的應用中，基礎代碼使用 Native 來實現就會有不少好處。好比 Navigation 組件就是一個很好的例子。

React Native 官方和社區有不少 navigation 的實現。但作的比較好的只有兩個：

NavigationiOS：不能跨平臺；
react-native-navigation：跨平臺，可是沒法知足Airbnb App的須要。

Airbnb 須要從 Native 的導航到 React Native 上，又能導航回來。惟一能作的就是本身實現。

Airbnb 利用每一個平臺相應的 Native 組件來實現一個跨平臺的 navigation，並提供成 JavaScript API。

爲了共享原生的 Navigation，Airbnb 採用多個 React Root View 共享一個 Bridge 的方式來實現。

更多的實現細節和 React API 能夠參看大會視頻。

優勢

nagivation 使用使用 Native 實現提供 React Native API 的優點有：

便於在 Native 和 React Native 以前切換；
navigation 狀態得以保存，而且快速切回來；
native 切換，效果好，性能高；
渲染時可配置；
能夠遵循不一樣平臺的設計原則，避免本身實現的各類細節和 Bug；
容許複雜的自定義。

開源

Airbnb 本身研製的 native-navigation 一道開源了，歡迎使用！

Moving Beyond Animations to User Interactions at 60 FPS in React Native

哪一種應用你以爲是優秀的？首先動畫的幀率達到60，並且用戶交互起來須要有真實的感受。

若是純粹經過 React Native 提供的 JS API 來實現有什麼問題，看下圖：

不斷地響應用的事件，並經過 Bridge 通知 JS，經過修改 React 組件的狀態來實現動畫。JavaScript 和 Native 通訊有消耗，事件一多就會掉幀。動畫天然也無法流暢了。

Tal Kol 的作法就是提供給 JS 聲明式的 API，JavaScript 只通知 Native 該如何響應用戶手勢，具體動畫的過程由 Native 來控制。

具體以下圖示意：

在 iOS 下咱們能夠藉助原生的物理引擎來實現，而在 Android 下，咱們就得開發本身的物理引擎來實現一樣的效果。下面是物理：

接下來就是開源啦！

react-native-interactable 已經開源，並且能夠到商店中搜索 React Native Interactions，下載 Demo App 體驗！

閃電分享#2

You Don't Need a Fancy Framework to Use GraphQL with React

分享的內容在這篇文章You don’t need a fancy framework to use GraphQL with React 裏均可以看到。Samer Buna 給咱們介紹了一種模式如何在不使用框架（Relay 或者 Apollo）的狀況下，輕鬆地使用 GraphQL。

// In src/components/App.js
App.GraphQL = `
  query GetArticleList($apiKey: String!) {
    viewer(apiKey: $apiKey) {
      data: articles {
        ...ArticleListFragment
      }
    }
  }
  query GetArticle($apiKey: String!, $articleId: String!) {
    viewer(apiKey: $apiKey) {
      data: findArticle(id: $articleId) {
        ...ArticleFragment
      }
    }
  }
  ${ArticleList.GraphQL}
  ${Article.GraphQL}
`;複製代碼

Samer 認爲能夠像 React 組件樹同樣，組織對應組件的 GraphQL 查詢語句。而後由根組件發出查詢，子組件像個傻瓜同樣，接受來自父組件的數據便可。

除此以外，一個更有意思的東西是，Samer 開源了 graphfront.com/——GraphQL Backend as a Service，一個能夠在線配置 GraphQL 後端 API 的服務；包括 graphfront 和 graphfront-ui。