React 16 兩三事

02-08

這兩天 React 16 發布了，同時， React 16 與 15.6.x 都已經切換到 MIT 協議。版權的熱議與一些公司的決斷對於整個社區而言看起來是個好事，同時，也給前端的組件化帶來了更多的思考。

對於 React 16 的相關信息，有幾個內容可以去看下：

Fiber 框架相關信息：如何理解 React Fiber 架構？
React 官方 Blog 的發布： React v16.0 - React Blog
Facebook 發布的 React 16 改寫背後的經歷 https://code.facebook.com/posts/1716776591680069/react-16-a-look-inside-an-api-compatible-rewrite-of-our-frontend-ui-library/

React 16 大致有以下改變：

新的 Fiber render 引擎：以支持許多原來做不到的關於 render 的特性
支持非阻塞式渲染
render 支持 fragments (數組) 與字元串類型
支持 Error 邊界捕獲
添加 ReactDOM.createPortal 方法來進行組件 DOM 節點之外的渲染，這個特性使得模態框、popover、tooltip 之類的渲染變得更加方便。BTW, 這個本來是另一個開源庫的思路： tajo/react-portal
支持 stream 的 server side render
減少的體積：大致減少了 30% 的文件體積

可能需要關注的 Breaking Changes:

unstable_renderIntoContainer, unstable_handleError 等之前的內部特性有改變，如果有依賴庫用到了的話可能需要注意
生命周期的順序更加穩定，尤其是子節點的 componentWillMount 總會發生在父節點的 componentWillUnmount 之前
componentDidUpdate 方法不再能夠獲取 prevContext 參數
Shallow Renderer 不再調用 componentDidUpdate 方法，並且不再提供 unstable_batchedUpdates 方法（這個似乎會影響到一些之前的測試代碼）
不再有 react-with-addons.js 這個庫。目測這個之後會有開源庫來提供類似功能，但 React 官方提倡的是分別引用不同的 npm 庫來做 addons 的事情

Rewrite 的過程

Facebook 的 Blog 在這方面介紹得挺細的： https://code.facebook.com/posts/1716776591680069/react-16-a-look-inside-an-api-compatible-rewrite-of-our-frontend-ui-library/

其中有些內容感覺還是挺值得借鑒學習的：

並沒有 fork branch，而是用了一個 useFiber 的布爾值作為 Flag 來在運行時決定使用那個引擎。關於多人維護的代碼在版本管理時使用什麼策略這個問題也是老生常談了，我跟小夥伴們也討論過 flag 的方式，雖然挺理想的但還真不是什麼團隊都玩得來的。
最開始的開發流程，基本上是實現最基礎的 API subset ，然後跑單元測試
測試過程中也在調整 test case，因為有可能有些問題之前沒測到，或者是之前的測試依賴了一些內部方法
Dogfooding：在 Facebook 的內部工具以及對外產品上灰發新版本 React 作為測試，對外的大型產品主要從 http://messenger.com 開始。說實話這個對於 UI 框架而言真夠大膽的……

作為開發者

反正我是不會這麼快遷移到 React 16 的……尤其是對於現有產品平台。

反而，之前的版權事件讓我有些去 React 化的傾向，或者更確切的說，弱化 UI 框架對於項目的影響的傾向。具體怎麼做可能還值得進一步探討，比如更多使用 Web 標準的方案比如 CSS 而非與框架綁定的 CSS in JS；比如基礎組件更多考慮純粹 Vanilla JS 實現，然後再用框架封裝；有哪些邏輯可以進一步分離，如何分離，等等。

React 之後會怎樣也還真不好說，這一次版權事件感覺並沒有就這麼終結，應該還會潛移默化地進一步對社區造成長久影響，需要進一步觀望。