深刻理解React(二) —— 數據流和事件原理

版權聲明：本文由左明原創文章，轉載請註明出處: 
文章原文連接：https://www.qcloud.com/community/article/158

來源：騰雲閣 https://www.qcloud.com/community

 

這個，叫作竹筧，是中日傳統禪文化中常見的庭院裝飾品，它的構造可簡單可複雜，但原理很簡單，好比這個竹筧，水從竹筧頂部入口流入內部，並按照固定的順序從上向下依次流入各個小竹筒，而後驅動水輪轉動。對於強迫症患者來講，觀賞竹筧的絕對是一種很享受的過程的最愛，你會發現這些小玩意居然能這麼流暢的協調起來，好神奇。

若是竹筧是一個組件的話，那麼水就是組件的數據流。

在React中，數據流是自上而下單向的從父節點傳遞到子節點，因此組件是簡單且容易把握的，他們只須要從父節點提供的props中獲取數據並渲染便可。若是頂層組件的某個prop改變了，React會遞歸地向下遍歷整棵組件數，從新渲染全部使用這個屬性的組件。

這個是前面看到的 KM 熱點問題組件，擁有一個叫作 articles 的屬性。

在組件內部，能夠經過this.props來訪問props，props是組件惟一的數據來源，對於組件來講：

props永遠是隻讀的。

不要嘗試在組件內部調用setProps方法來修改props，若是你不當心這麼作了，React會報錯並給出很是詳細的錯誤提示。

組件的屬性類型若是不進行聲明和驗證，那麼極可能使用者傳給你的屬性值或者類型是無效的，那會致使一些意料以外的故障。好在React已經爲咱們提供了一套很是簡單好用的屬性校驗機制——

React有一個PropTypes屬性校驗工具，通過簡單的配置便可。當使用者傳入的參數不知足校驗規則時，React會給出很是詳細的警告，定位問題不要太容易。

PropTypes包含的校驗類型包括基本類型、數組、對象、實例、枚舉——

以及對象類型的深刻驗證等等。若是內置的驗證類型不知足需求，還能夠經過自定義規則來驗證。
若是某個屬性是必須的，在類型後面加上 isRequired 就能夠了。

React的一大創新，就是把每個組件都當作是一個狀態機，組件內部經過state來維護組件狀態的變化，這也是state惟一的做用。

state通常和事件一塊兒使用，咱們先看state，而後看看state和事件怎樣結合。
這是一個簡單的開關組件，開關狀態會以文字的形式表如今按鈕的文本上。
首先看render方法，返回了一個button元素，給button註冊了一個事件用來處理點擊事件，在點擊事件中對state的on字段取反，並執行 this.setState() 方法設置on字段的新值。一個開關組件就完成了。

組件渲染完成後，必須有UI事件的支持才能正常工做。

React經過將事件處理器綁定到組件上來處理事件。
React事件本質上和原生JS同樣，鼠標事件用來處理點擊操做，表單事件用於表單元素變化等，Rreact事件的命名、行爲和原生JS差很少，不同的地方是React事件名區分大小寫。
好比這段代碼中，Article組件的section節點註冊了一個onClick事件，點擊後彈出alert。
有時候，事件的處理器須要由組件的使用者來提供，這時能夠經過props將事件處理器傳進來。

這個是剛纔那個Article組件的使用者，它提供給Article組件的props中包含了一個onClick屬性，這個onClick指向這個組件自身的一個事件處理器，這樣就實現了在組件外部處理事件回調。

這是一個React組件實現組件可交互所需的流程，render()輸出虛擬DOM，虛擬DOM轉爲DOM，再在DOM上註冊事件，事件觸發setState()修改數據，在每次調用setState方法時，React會自動執行render方法來更新虛擬DOM，若是組件已經被渲染，那麼還會更新到DOM中去。

這些是React目前支持的事件列表。

React的組件擁有一套清晰完整並且很是容易理解的生命週期機制，大致能夠分爲三個過程：初始化、更新和銷燬，在組件生命週期中，隨着組件的props或者state發生改變，它的虛擬DOM和DOM表現也將有相應的變化。

首先是初始化過程，這裏會着重講，須要充分理解。
組件類在聲明時，會先調用 getDefaultProps() 方法來獲取默認props值，這個方法會且只會在聲明組件類時調用一次，這一點須要注意，它返回的默認props由全部實例共享。
在組件被實例化以前，會先調用一次實例方法 getInitialState() 方法，用於獲取這個組件的初始state。
實例化以後就是渲染，componentWillMount方法會在生成虛擬DOM以前被調用，你能夠在這裏對組件的渲染作一些準備工做，好比計算目標容器尺寸而後修改組件自身的尺寸以適應目標容器等等。
接下來就是渲染工做，在這裏你會建立一個虛擬DOM用來表示組件的結構。對於一個組件來講，render 是惟一一個必須的方法。render方法須要知足這幾點：
1.只能經過 this.props 或 this.state 訪問數據
2.只能出現一個頂級組件
3.能夠返回 null、false 或任何 React 組件
4.不能對 props、state 或 DOM 進行修改
須要注意的是，render 方法返回的是虛擬DOM。

渲染完成之後，咱們可能須要對DOM作一些操做，好比截屏、上報日誌、或者初始化iScroll等第三方非React插件，能夠在 componentDidMount() 方法中作這些事情。固然，你也能夠在這個方法裏經過 this.getDOMNode() 方法取得最終生成DOM節點，而後對DOM節點作愛作的事情，但須要注意作好安全措施，不要緩存已經生成的DOM節點，由於這些DOM節點隨時可能被替換掉，因此應該在每次用的時候去讀取。

組件被初始化完成後，它的狀態會隨着用戶的操做、時間的推移、數據更新而產生變化，變化的過程是組件聲明週期的另外一部分 ——

更新過程。

當組件已經被實例化後，使用者調用 setProps() 方法修改組件的數據時，組件的 componentWillReceiveProps() 方法會被調用，在這裏，你能夠對外部傳入的數據進行一些預處理，好比從props中讀取數據寫入state。

默認狀況下，使用者調用組件的 setProps() 方法後，React會遍歷這個組件的全部子組件，進行「灌水」，將props從上到下一層一層傳下去，並逐個執行更新操做，雖然React內部已經進行過不少的優化，這個過程並不會花費多少時間，可是程序員裏永遠不缺少長期性能飢渴的同窗，不用擔憂，React有一個可以解決你性能飢渴的辦法——shouldComponentUpdate()。
有時候，props發生了變化，但組件和子組件並不會由於這個props的變化而發生變化，打個比方，你有一個表單組件，你想要修改表單的name，同時你可以確信這個name不會對組件的渲染產生任何影響，那麼你能夠直接在這個方法裏return false來終止後續行爲。這樣就可以避免無效的虛擬DOM對比了，對性能會有明顯提高。
若是這個時候有同窗仍然飢渴難耐，那麼你能夠嘗試 不可變數據結構(用過mongodb的同窗應該懂)。
組件在更新前，React會執行componentWillUpdate() 方法，這個方法相似於前面看到的 componentWillMount()方法，惟一不一樣的地方只是這個方法在執行的時候組件是已經渲染過的。須要注意的是，不能夠在這個方法中修改props或state，若是要修改，應當在 componentWillReceiveProps() 中修改。
而後是渲染，React會拿此次返回的虛擬DOM和緩存中的虛擬DOM進行對比，找出【最小修改點】，而後替換。
更新完成後，React會調用組件的componentDidUpdate 方法，這個方法相似於前面 componentDidMount 方法，你仍然能夠在這裏能夠經過 this.getDOMNode() 方法取得最終的DOM節點。

香港電影結尾常常看到一個劇情，就是英雄戰勝了壞人，而後警察出來擦屁股——

警察偶爾還能立功，而 componentWillUnmount 最可憐，他除了擦屁股什麼也作不了。
你能夠在這個方法中銷燬非React組件註冊的事件、插入的節點，或者一些定時器之類。這個過程可能容易出錯，好比綁定了事件卻沒銷燬，這個React可幫不了你，你本身約的炮，含着淚也要打完。

兩節內容講了上手React所必備的知識。
後面講價值。

直出有多快我就很少說了。
由於有虛擬DOM的存在，React能夠很容易的將虛擬DOM轉換爲字符串，這便使咱們能夠只寫一份UI代碼，同時運行在node裏和和瀏覽器裏。

在node裏將組件HTML渲染爲一段HTML一句話便可。
不過圍繞這個renderToString咱們還要作一些準備工做。代碼有點多，你們作好心理準備。

這是一個express的路由方法，在這裏：
1.從後臺server或數據庫等來源拉取數據
2.引入要渲染的React組件
3.調用React.renderToString()方法來生成HTML
4.最後發送HTML和數據給瀏覽器

這裏爲了方便描述，沒有寫拉取數據的代碼，你們自行腦補。

須要注意的是這裏的JSON字符串中可能出現結尾標籤或HTML註釋，可能會致使語法錯誤，這裏須要進行轉義。

頁面的示例代碼原本打算用你們更熟悉的HTML，但發現代碼量太多了PPT裏一頁放不下，因此換成了jade代碼，沒用過jade的同窗也順便了解一下，我也順便給jade打個廣告。
這個頁面作了X個事：
1.將前面在action裏生成的HTML寫到#container元素裏
2.引入必須的JS文件
3.獲取action提供的數據
4.渲染組件

這就是React的服務端渲染，組件的代碼先後端均可以複用。
<有沒有沒理解清楚的同窗？>

是否是感受React挺牛逼的？你們覺得React就這麼點能耐嗎？

React可以用一套代碼同時運行在瀏覽器和node裏，並且可以以原生App的姿式運行在iOS和Android系統中，即擁有了web迭代迅速的特性，又擁有原生App的體驗。
這個姿式叫作 React-Native。
這是React和React-Native在github上的數據，能夠看出React-Native也是至關熱門——由於React-Native可以使React的價值最大化，這個價值是什麼呢——對業務來講，意味着不須要爲了作終端版本就招聘和前端等量人力的終端開發，同時意味着咱們成爲全棧工程師有了一個捷徑。

瞭解iOS開發的同窗都知道，水果公司對應用上架的審覈效率實在讓人無力吐槽，不少團隊上一個版本還沒審覈結束，下一個版本就已經作好了。而React-Native支持從網絡拉取JS，這樣iOS應用也可以像web同樣實現快速迭代了。

這個是react-native的調試過程

做爲一個沒寫過一句Object-C代碼的web前端開發，我只用了一天時間就上手了react-native，而後用了半天時間作出了一個簡單的demo頁面，能夠看到react-native的生產效率仍是很是高的。

單元測試顧名思義，是對各個模塊進行最小範圍的測試，容易。
咱們來演示一個checkbox的單元測試過程。

看代碼

由於虛擬DOM的存在，使得react的代碼很容易作好單元測試，這是上面那段代碼的測試用例，經過karma執行後便可看到結果。

因此你可能須要這些東西

課後練習

（若是你已經看到這裏了，爲什麼再也不花1分鐘思考一下上面3個問題）

上一期React技術文章：

深刻理解 React （一） - JSX和虛擬DOM