知乎pure render專欄創辦人@流形：選擇React這條路，很慶幸

本文僅用於學習和交流目的，不得用於商業目的。非商業轉載請註明做譯者、出處，並保留本文的原始連接：http://www.ituring.com.cn/Art...

陳屹（流形）

前端架構師，就任於阿里巴巴。熱衷開源事業，終年專一於前端架構、數據可視化、Node.js等領域，知乎專欄pure render的創辦人。

segmentfault社區活躍地址：https://segmentfault.com/u/ar...

專欄寫做近一載，積累了 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 框架。

---

——更多訪談

---

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