知乎pure render專欄創辦人@流形：選擇React這條路，很慶幸（圖靈訪談）

陳屹（流形）

前端架構師，就職於阿里巴巴。熱衷開源事業，長年專注於前端架構、資料視覺化、Node.js等領域，知乎專欄pure render的創辦人。

專欄寫作近一載，積累了 24 篇經典沉澱，大都關於 React 相關的原理與實踐分享展開。《深入 React 技術棧》的部分內容就基於專欄文章，通過整理提煉、糾錯與升級，內容更加科學、系統。為了照顧到深度，還有很多內容完全重新編寫，系統講述了 React 與其技術棧的使用方法及工作原理。

訪談內容：

前端技術那麼多，為什麼選擇了React？

當初選擇 React 的理由很簡單，只是為了解決業務上的痛點。前年，產品架構還是 jQuery 和 Backbone。但隨著產品的業務複雜度不斷增加，資料層的邏輯基本上還是鏈路很短的資料請求，而 View 層的互動邏輯卻變得越來越複雜，難以維護。

選型時，Angular 和 React 是重點考慮的兩個物件。其中，Angular 比較成熟，也積累了很多粉絲，雖然嘗試過，但不符合我們的場景，需要對現有構架作出較大的調整。我們需要的是，更輕量級、不繫結某種架構的技術，而且最重要的是，方便元件化的選擇。實踐後，決定下注 React。用 React 封裝了一套元件與Backbone model 配合。

選擇核心技術或庫時，需要對業務擔責。高成本的重構會給業務帶來不必要的影響。發展、可持續、承前啟後的考慮是首要的。

隨著業務的發展，團隊也在不斷成長，不斷探索著最佳實踐方案。現在重新回顧一路的發展，非常慶幸選擇 了 React。

如何看待同樣以“輕便、易上手”著稱的Vue？跟Vue相比，React有哪些優勢？

Vue 使用的是 web 開發者更熟悉的模板與特性，React 的特色在於函數語言程式設計的理念和豐富的技術選型。Vue 比起 React 更容易被前端工程師接受，這是一個直觀的感受；React 則更容易吸引在 FP 上持續走下去的開發者。我想更多還是口味的不同。

如果一定要說 React 的優勢，就是它活躍的生態圈。在 npm 社群搜尋 React 關鍵詞，會出現 21k+ 的庫，而開源時間更久的 Angular 卻只有 9k+，足可見開發者對其追捧的程度。另外，React 還是 FB 技術佈局上重要的一部分，包括已開源的 React Native，未來的 React VR。當然，Vue 也有 Weex。

React 和 Vue 兩者發展速度都很快，對於產品技術選型來說，活躍程度與生態發展可能比庫本身帶來的優勢更為重要。現在的框架之爭太多，我的建議是，當你選定之後，沒必要急著切換，因為它們都可以完成中大規模的應用。從學習的角度，兩者都值得學習。

編寫《深入React技術棧》的原因有哪些？它的獨特之處在哪裡？

寫這本書的時候，國內只有一本 React 相關的的入門書籍，並沒有深入細節與實踐方面的內容。而在這方面，pure render 專欄沉澱了很多經驗。同時，踩過很多坑的經驗，讓我相信自己有能力寫一本書更好地回饋社群。在此，感謝編輯老師的信任，戰友們、朋友們給予的支援和鼓勵。

要說本書的獨特之處，一定在於每一部分都會去分析原始碼。儘管原始碼並不是開發者所要關注的，我想傳達的是，讀原始碼是學習技術最方便的途徑，尤其對於非常活躍的前端開源社群來說。

在《深入React技術棧》一書中，為什麼會選擇“元件化、Flux和Redux、server、視覺化”四個維度來講解React？

全書從 React 元件化的思想和用法講起，再講到其背後的原理。元件化是前端工程中非常重要的部分，自前端開發的早期，工程師就一直在嘗試用物件導向的理念來封裝元件，直到今天也沒有停下來。

到富客戶端應用的年代，只有元件化已經不夠了，先驅們借來了分層思想，先是 Backbone 站在了高點，到後來的百花齊放。說到 React 技術棧，Flux 應用架構起了個頭兒，到 Redux 的誕生，算是完成了工程化的最後一塊拼圖，這是一個漸進的發展過程。結合 server render 完整打通了今天前端架構 SPA 的所有部件。

視覺化在前端圈的地位很獨特，已經有越來越多的前端轉向專職的視覺化工程師。視覺化在這個領域有著不同於傳統前端的開發方式，書中的內容也只是結合 React 開發的實踐而已。

說到能夠寫作的程式設計師或是能夠程式設計的作家，這兩種人都是相當稀少。寫完《深入React技術棧》一書，可以給我們分享下你的切身感受嗎？

其實在互聯技術上並不少吧。在國內知乎，SegmentFault，還有各種社群部落格上可以看到不少善於分享的大咖。

說說寫書過程中的感受。其實，從一開始的思路到最後成型的佈局，之間產生了不小的改變，即使到最後時刻目錄都在變動，真是不斷挑戰著自己。況且，React 技術棧在半年裡的變化也不小，我會擔心內容過時，承受很快被淘汰的命運，也許每一位技術書的作者都會經歷這種痛苦。

當然，看到很多讀者給我發來私信，表達學習到很多知識的時候，我想付出的一切都是值得的吧。

在知乎上創辦專欄pure render，在SegmentFault等技術社群分享知識，不會分散精力影響技術研究嗎？

分享並不是任務，是技術研究的一部分，並不會分散太多精力。我曾經說過，寫文章並不單是為了別人，它可以把自己的想法或成果記錄下來，是一件比較純粹的事。

寫文章也是為了交流。交流，更確切地說是，思想上的碰撞，碰撞那些還不堅定的想法，在說服與被說服的過程中共同進步。你理解了他人的經驗，也完善自己的經驗世界。

創辦pure render專欄也有帶領前端團隊在技術道路上作沉澱的考慮。每一篇文章我或團隊都會作稽核，期望量少而精。現在，我也會試著邀請一些優秀人士給更多關注的朋友分享技術。

我瞭解到，你熱衷開源事業。有哪些React開源專案推薦給大家學習？

如之前所說，React 社群在前端社群是非常活躍的，這一點非常像過去的 jQuery 開源社群。有非常多的輪子可以選擇，卻也帶來選擇上的困擾。

我在書中基本上把應用所需要的庫都有說到。元件庫方面，antd 已經被大家熟悉，如果想要定製元件，在 antd 背後的 react-component 做得也是非常優秀。另外，material-ui 也是一個很好的選擇，尤其對於喜歡這套 UI 的開發者。

早期， Flux 衍生框架非常多，直到社群出現了 Redux、React Router、Redux Saga，Immutablejs 等最佳實踐後才算消停。當然，如果你還是一個新手，還是建議你堅持使用 Redux，理解 Redux。

視覺化方面，還是要推薦一下 Recharts。這個視覺化庫，是基於 React 和 D3，非常符合 React 構建元件的思想。

React 優秀的開源專案每週每月都會有，關注社群的動態也是我們前端工程師必備的技能。

讀者希望陳老師能分享下你自己“從剛接觸前端到現在擁有如此的技術沉澱”一路上的經驗。如果真要踏上React學習之路，有哪些“坑窪”是值得注意，哪些“美景”是不容錯過的？

我瞭解到，很多剛開始學習前端的學生就想一頭扎到 React 或其它體系中去，這是非常危險的想法。比如我在專欄中提過，去 jQuery 的決定是和應用本身的特質相關的。如果說只是很簡單的頁面，並沒有太多和服務端互動的內容，我還是首推 jQuery。因此，在你踏上 React 學習之路前，還請打好基礎尤其是 DOM。

對於“坑窪”或是“美景”，我就說兩點。第一，關注元件的複用粒度，儘可能保持元件的可擴充套件性，支援可控與不可控。第二是資料層的抽象，不同的業務需要有不同級別的資料抽象，有些越簡單越好，有些封裝得越厚越好。最重要的是根據業務的需要，保持介面與資料抽象的平衡。

在研究React的道路上，未來你會專注哪些方向？

走在 React 這條路上，很容易思考函數語言程式設計的各種特性對複雜應用帶來的好處。但函數語言程式設計在生產環境中會對業務抽象帶來更高的難度。很多人都在嘗試用 React 的理念創造小而美的輪子，如 inferno，也可能會自己實現一套去匹配業務的需要。

說到未來，我可能會關注 FRP，它簡化了現有架構的概念，更適合於使用者介面的開發。Mobx 就作出了很多努力，同樣，我也會關注更純粹的 elm、cyclejs 這些 FRP 框架。

---

——更多訪談

---

更多精彩，加入圖靈訪談微信！