React 生態系統：從小白到大神

GitChat 做者：Yeh.
原文： React 生態系統：從小白到大神
公衆號：「GitChat 技術雜談 」，一本正經的講技術

引言

要了解React的思想，還得從下面這張圖提及。

The State-Action-Model (SAM) Pattern

The State-Action-Model (SAM) Pattern

話說2016年2月的一篇文章no-more-mvc-frameworks描述了一種新的函數式、響應式模型，而它的思想來源正是來自React和TLA+，這一模型就叫作SAM模型。

SAM模型讓前端開發人員更專一於從模型中去創建視圖，而不會受牽制於基礎API。所以SAM徹底符合軟件架構的重要設計原則。這種模型的最佳實踐莫過於React與Angular了，隨着他們的發展，前端架構思想開始了轉變。

雖然React官網將React定位爲建立用戶界面的JS庫，但我想說的是，「React is just the View in MVC」這一說法太過委婉了。React所帶來的是整個前端技術棧的進化，各類函數響應式框架逐漸在完善。

隨着React的發展和流行，圍繞着React的生態系統已經逐漸造成。而從React小白到大神，必需要經歷三個境界，但總歸起來就五個字：「就解問題嘛」——出自「阿里掃地僧」多隆。所以，本文經過描述每一個知識點解決了哪些問題的方式來爲你們介紹React生態系統。

###1、React龐大的體系

1.1 ReactJS

ReactJS到底解決了哪些問題呢？先來一份總結的ReactJS特色：

• 高效：React經過虛擬DOM和Diff算法，最大限度地減小與DOM的交互和渲染。——提升運行效率

• 組件化：經過 React 構建組件，使得代碼更加容易複用，適應大型項目開發。——提升可維護性和複用性以及開發效率

• 模塊化：經過模塊化工具庫來解決模塊化問題——提升可維護性和複用性

• 單向數據流：React 實現了單向響應的數據流，從而減小了重複代碼，這也是它爲何比傳統數據綁定更簡單。提升可維護性。

一言以蔽之，ReactJS解決了前端技術規劃中應該考慮的這幾件事：組件化、模塊化、開發效率、運行效率、可維護性…

1.2 React生命週期

下圖很直觀地描述了React生命週期的整個過程：

React生命週期

React生命週期

這裏有個不錯的github項目：react-pxq。這是的一個react + redux項目，其中滲透出了做者（bailicangdu）對react的理解，能很好的幫助你們快速上手react。生命週期這東西說簡單也簡單，說難也難。有的人說，不就是幾個階段嗎？但若是你是去面試，有經驗的面試官可能會出這樣幾道題：1.React在初始化和更新的時候會觸發的鉤子函數？2.父組件在更新狀態的時候父組件與子組件的生命週期順序是怎麼執行的？針對第1個問題，就算不懂的人看幾眼背一下都能答出來。而第2個問題就比較考驗你的知識深度了。首先須要知道子組件在何時會被渲染？它必定會被渲染嗎？有什麼方法可以減小它的渲染？一大堆引伸的知識點，若是能應對如流（最好的方法是看源碼咯），相信你會給面試官留下好印象。

1.3 React Router

React Router是React中使用的路由庫，經過管理URL來管理組件及對應的狀態。Router組件自己只是一個容器，真正的路由要經過Route組件定義。Router組件支持嵌套路由、支持通配符，能讓你輕鬆控制整個項目的路由結構。

1.4 Redux

Redux跟React沒有直接的關係，自己能夠支持React、Angular、Ember等等框架。Redux實際上是Flux-like 更優雅的寫法，下圖對比了Flux與Redux的數據流向：

Flux與Redux的數據流向

Flux與Redux的數據流向

經過react-redux這個庫，能夠方便的將react和redux結合起來：React負責頁面展示，Redux負責維護/更新數據狀態。大體過程爲：當用戶在View中觸發事件產生Action，Action 進到 Reducer，Reducer根據Action Type去匹配對應處理的動做，而後返回一個新的狀態。View則由於檢測到狀態更新而進行重繪。Redux只有一個Store負責存放整個App的狀態，而惟一能改變狀態的方法只有發送Action。Redux社區中使用比較多的庫有：redux-sagas、redux-gen、redux-loop、redux-effects、redux-side-effects、redux-thunks、rx-redux、redux-rx...

1.5 React測試

目前廣大開發者偏向使用Airbnb團隊開發的enzyme，它也能夠與其餘測試工具如Jest、Mocha等配合使用，好比咱們使用jest-enzyme，因爲Jest是Facebook開發而且是在Jasmine測試框架上演變而來的，斷言格式咱們比較熟悉，所以你們可能更容易上手。Jest的目標是減小測試一個項目所要花費的時間和認知負荷，它提供了大部分咱們須要的現成工具：快速的命令行接口、Mock工具集以及它的自動模塊Mock系統，總的來講就是讓測試變得更簡單。

1.6 React Native

RN是在Facebook所提出的核心概念Learn once, write anywhere所誕生的產物，着力於提升多平臺開發的開發效率。咱們能夠同時爲android和ios兩個平臺開發App，只須要根據兩個平臺不同的地方去作一些調整便可。RN主要負責UI部分，而原生主要負責交互和數據處理。RN屬於hybrid開發，而且與原生無縫鏈接，相比Web App和Native開發，RN取長補短，集合了二者的優點。RN開發的APP能夠跳過App Store審覈，遠程更新代碼，提升迭代頻率和效率，既有Native的體驗，又保留React的開發效率。
RN的原理是將React代碼轉化爲原生API，iOS一套，Android一套。RN在一開始生成OC模塊表，而後把這個模塊表傳入JS中，JS參照模塊表，就能間接調用OC的代碼。

至關於買了一個產品（OC），對應一份說明書（模塊表），用戶（JS）參照說明書去操做這個產品。
如何學習RN呢？能夠跟着git上的awesome系列去進階。從源碼角度看RN，主要須要瞭解RN如何作到JS和OC交互、RN的啓動流程是怎樣的、如何加載JS源碼、UI控件的渲染流程、事件處理流程以及RN與iOS之間的通訊方式等。

作React還須要懂什麼？

1.7 Node

Node打破了過去JS只能在瀏覽器中運行的局面。先後端編程環境的統一，大大下降了先後端轉換所須要的上下文交換代價。Node就是瀏覽器在協議棧另外一邊的倒影，雖然不處理UI，卻與瀏覽器有着相同的機制和運行原理。其高性能並行I/O使得分佈式開發更加高效，利用穩定接口可提高web渲染速度，也十分適合作實時應用開發。第2部分將闡述Node在先後端中的角色做用。

1.8 NPM與Yarn

咱們知道Node的包描述文件是一個JSON文件，用於描述非代碼相關的信息。而NPM則是一個根據包規範來提供Node服務的Node包管理器。它解決了依賴包安裝的問題，卻面臨着兩個新的問題：

• 安裝的時候沒法保證速度和一致性。

• 安全問題，由於NPM安裝時容許運行代碼。

因而Yarn就出現了，不要慌，它並無試圖徹底取NPM，不過Yarn確實也是能夠完美替代npm的。

1.9 模塊化開發

隨着web應用的發展，前端的業務邏輯愈來愈複雜，代碼也愈來愈多，各類問題就暴露出來了：全局變量污染、函數命名衝突、依賴關係混亂等問題嚴重阻礙了前端開發的發展，JS模塊化勢在必行。經過開發者不斷地嘗試，出現了各類規範和實踐：

CommonJS

Node.JS首先採用了js模塊化的概念。Node.js服務器端經過exports、module.exports來輸出模塊，並使用require同步載入模塊，而瀏覽器端的可使用Browserify實現。

AMD

AMD規範用於異步加載模塊，主要用於瀏覽器端，固然也支持其餘js環境，主要應用有requireJS。

ES6 Module

ES6標準定義了JS的模塊化方式，目的是取代CommonJS、AMD、CMD等規範，一統江湖，成爲通用的模塊化解決方案。但瀏覽器和Node端對ES6的支持度還不是很高，須要用Babel進行轉譯（Babel編譯器能夠將ES六、JSX等代碼轉換成瀏覽器能夠看得懂的語法）。

Gulp/Grunt+Webpack/Browserify

在構建前端項目資源，使用自動化工具協助進行自動化程序碼打包、轉譯等重複性工做，能夠大幅提高開發效率。

• Gulp

  Gulp和Grunt同樣是一種基於任務的構建工具，可以優化前端工做流程。

• Webpack

  webpack傻瓜式的項目構建方式解決了模塊化開發和靜態文件處理兩大問題。但隨着項目愈來愈大，特定需求的出現就使得webpack愈來愈難配置了。所以webpack在沒太多特定需求的項目使用是沒有問題的，固然，webpack的將來確定是圍繞ES的支持度、構建速度與產出代碼的性能和用戶體驗來建設的。其將來的重要關注點：

  • 高性能的構建緩存

  • 提高初始化速度和增量構建效率

  • 更好的支持Type Script

  • 修訂長期緩存

  • 支持WASM模塊支持

  • 提高用戶體驗

• Browserify

  Browserify是基於Unix小工具協做的方式實現模塊化方案的，輕便且配置容易，管道形式的組織則讓開發者很容易插拔或修改其中某一環節的操做。

  至於怎麼配合使用，我以爲仁者見仁智者見智，確實是很差下定論，只有親身體驗才能擇更好者而用吧。

• ES2015/ES6

  咱們都知道ECMASCRIPT是組成JS的三要素之一，ES6其第6個版本，ES的歷史確實也挺曲折的。經過ES6最經常使用的特性，咱們來了解ES6到底解決了什麼：

  • let, const（變量類型）：解決變量做用域泄露的問題。

  • Class, extends, super（類、繼承）：讓對象原型的寫法更加清晰、更像面向對象編程的語法，也更加通俗易懂。

  • Arrow functions（箭頭函數）：1.簡潔、簡潔、簡潔，2.解決this綁定的問題（繼承外面的this）。

  • Template string（模板字符串）：解決傳統寫法很是麻煩的問題。

  • Destructuring（解構）：避免讓API使用者記住多個參數的使用順序。

  • Default, rest（默認值、參數）：簡化，替代arguments，使代碼更易於閱讀。

ImmutableJS

咱們知道在JavaScript中有兩種數據類型：基礎數據類型和引用類型。在JavaScript中的對象數據是能夠變的，因爲使用了引用，因此修改了複製的值也會相應地修改原始值。一般咱們用deepCopy來避免修改，但這樣作法會產生資源浪費。而ImmutableJS的出現很好的解決了這一問題。

React的生態系統還有噓噓多多相關的知識，本文並不能全面涵蓋全部知識，望諒解。另外，推薦你們從git上的awesome系列去學習你想要學習的一門知識。若是是有英文而沒有中文，你們也能夠fork下來去作一些翻譯，爲大前端技術作作貢獻嘛！:-D

###2、先後端架構分離

先後端分離的分層架構圖

先後端分離的分層架構圖

不少人都有過MVC架構的開發經驗，從Spring MVC開始，寫JSP，再到使用freemarker，而後再到狹義的先後端分離，也就是Web端經過ajax調用接口，使用JS把數據渲染到頁面上。之前後端人員套頁面，數據結構和業務邏輯混淆在一塊兒，項目愈來愈大後，維護起來特別的繁瑣。目前看到的先後端分離項目都是上圖所示這種形式去實現的。尤爲是在大公司，基本都是採用面向服務架構的開發模式，團隊開發中的溝通成本以及職責明確特別重要。而先後端分離的意義主要在於解耦，解耦後先後端職責劃分更明確，前端能作的事也愈來愈多，好比咱們能夠在Node層作些監控和日誌管理，將SSO登陸集成進Node層，使用PM2對Node作多進程管理。這樣以後，後端項目就能夠作成"微服務"式的架構。

從前端項目工程化管理的角度來看，後端項目"微服務"式架構有以下優點：

• 每一個項目都頗有針對性，僅關注某個業務方向。

• 每一個項目可由不一樣團隊獨立開發，互不影響，能快速響應需求、及時推出市場。

• 容許在頻繁發佈不一樣項目的同時保持系統其餘部分的可用性和穩定性：依賴少、構建速度快 & 上線速度快。

前端只與Node中間層進行數據通訊，Node層則經過thrift接口與後端服務進行數據通訊；Node 中間層的 API 設計遵循 RESTFul 的架構風格，而且都以 /api/* 作爲前綴；Node 中間層能夠視狀況添加緩存服務

###3、前端工程化

現代化的前端開發已經不只僅是業務代碼自己，而是涉及了不少方面的需求，好比：開發需求、共享需求、性能需求、部署需求。

3.1 開發需求

若是是新團隊，在開始一個前端項目時，咱們會先進行技術選型，而後定義代碼規範，再根據業務模塊拆分進行項目目錄規劃，這些相關的需求都算做前端開發需求。若是在成熟團隊中，可能已經有技術沉澱了，怎麼去優化和改進以及文檔化就成爲咱們須要去琢磨的事了。

代碼規範

ESLint是一個用來識別 ECMAScript 而且按照規則給出報告的代碼檢測工具，使用它能夠避免低級錯誤和統一代碼的風格。咱們能夠方便的在配置文件中配置本身想要的風格規範，一般推薦使用Airbnb JavaScript或者google的規範。

CSS預處理

咱們可使用less或sass來優化css的開發過程，而若是考慮到瀏覽器兼容性的hack問題，咱們能夠用postcss做爲預處理工具幫咱們自動解決這些 hack。

熱更新

hmr可以在感知你的代碼有變更的狀況下自動調用編譯工具編譯源碼，而後經過 livereload 自動刷新瀏覽器，這樣作的話能節省你的調試時間。

Mock

因爲採用了先後端分離的開發模式，在真實開發中，爲了讓前端開發不受後端進度的影響，咱們須要對數據進行mock。先後端先約定API 接口定義，而後前端根據定義mock 接口。通常大公司會有本身的mock平臺，小公司若是沒有的話也可使用開源的mock工具。

3.2 共享需求

對於公司而言，快速高效地實現業務是終極目標，這對先後端來講都是挑戰。在前端團隊中，可以造成基礎組件庫和業務組件庫是一種必然需求。

因此在設計前端項目架構的時候，必定要考慮業務的組件化和可共享性。有人說開發通用組件是造輪子，其實造出符合本身的輪子未嘗不是一種領悟。共享需求主要有四種：基礎代碼共享、通用工具方法共享、基礎交互組件共享以及業務組件共享。

在組件方面，React提供了自然的組件結構，咱們只須要在開發過程當中，隱藏組件的內部實現，每一個組件更獨立，很容易造成可重用組件。

3.3 性能需求

如何對web資源的加載速度進行優化呢？

• JS/CSS 代碼壓縮

• JS/CSS 代碼合併

• 圖片壓縮

• CSS 圖片精靈或雪碧圖

這些過程均可以在前端工程的構建過程當中使用Grunt/Gulp、webpack等構建工具實現。

3.4 部署需求

前端工程一般是由多人維護的，因此會用代碼管理工具來管理源碼，而後將開發流程和部署流程與git結合起來。多人分支協做流程：用git flow來管理代碼分支。

###4、總結

實踐證實，圍繞着React所創建起來的生態系統以及組件化開發思想能有效地分解大規模應用的複雜度、提升資源複用率。簡單的說，React擁有如下你想要的特性：

• 同構渲染：服務器端和客戶端共用一套代碼，一份模板，兩端使用。

• 徹底組件化：自動分析加載頁面的靜態資源依賴。

• 生態圈：暢享全部 React 組件。

固然，使用React也有一些缺點，例如頁面 javascript 文件體積動輒上百KB，這就限制了在移動端項目上的使用。咱們能夠經過一些離線化方案，例如使用 LocalStorage 緩存等來儘可能的減小對大致積靜態資源的請求。

總的來講，React的生態系統大而全，若是沒有涵蓋的部分，還請海涵。僅此與各位dalao共享一些我的觀點，共同進步。

彩蛋

重磅 Chat 分享：

《高效學習，快速變現：不走彎路的五大學習策略》

分享人：
一名會在 B 站直播寫代碼，會玩雜耍球、彈 Ukulele、極限健身、跑步、寫段子、畫畫、翻譯、寫做、演講、培訓的程序員。喜歡用編程實現本身的想法，在 Android 市場上賺過錢，有屢次創業經歷。擅長學習，習慣養成，時間管理。身體力行地影響他人作出積極的改變！目前就任於 ThoughtWorks，致力於傳播快樂高效的編程理念。業餘創立軟件匠藝社區 CodingStyle.cn，組織超過30場技術活動。

Chat簡介：
說到學習呀，真是頭大喲：碎片化，沒有較長的連續時間來學習難專一，捧起書，手機卻在召喚：來呀，快活呀~ 反正有，大把時光~作不到，看了不少書，生活中卻作不到然並卵，學了方法和工具，找不到使用場景效率低，學習速度跟不上知識產生的速度記不牢，學習速度趕不上遺忘速度在這個知識氾濫、跨界競爭的年代，學習能力纔是核心競爭力。你想一想，過去一週，有沒有哪一件工做是不須要學習就能完成的？儘管如此重要，大部分人卻沒研究過學習這件事，覺得上下班路上打開「獲得」聽本書，就是碎片時間終身學習者了。

我是程序員，諮詢師，培訓師，這幾個角色都要求我必須學得又快又好。本場 Chat 將分析學習的「趨勢，原則，策略」，幫你站在更高的視角看待學習，從「內容，動機，交互，收益，資源」五方面制定策略，解決學習痛點，助你成爲高效學習者！

想要免費參與本場 Chat ？很簡單，「GitChat技術雜談」公衆號後臺回覆「高效學習」

這裏寫圖片描述