本文僅用於學習和交流目的，不得用於商業目的。非商業轉載請註明作譯者、出處，並保留本文的原始鏈接：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 框架。
——更多訪談
