通俗易懂地理解Redux

前言

一直對於redux處於只知其一;不知其二的狀態，有幸看到Wang Namelos老師在知乎上一段回答，認真讀了三遍，猶如醍醐灌頂，推薦給你們，內容以下：

Redux

從需求出發，看看使用React須要什麼：

1. React有props和state: props意味着父級分發下來的屬性，state意味着組件內部能夠自行管理的狀態，而且整個React沒有數據向上回溯的能力，也就是說數據只能單向向下分發，或者自行內部消化。理解這個是理解React和Redux的前提。
2. 通常構建的React組件內部多是一個完整的應用，它本身工做良好，你能夠經過屬性做爲API控制它。可是更多的時候發現React根本沒法讓兩個組件互相交流，使用對方的數據。而後這時候不經過DOM溝通（也就是React體制內）解決的惟一辦法就是提高state，將state放到共有的父組件中來管理，再做爲props分發回子組件。
3. 子組件改變父組件state的辦法只能是經過onClick觸發父組件聲明好的回調，也就是父組件提早聲明好函數或方法做爲契約描述本身的state將如何變化，再將它一樣做爲屬性交給子組件使用。這樣就出現了一個模式：數據老是單向從頂層向下分發的，可是隻有子組件回調在概念上能夠回到state頂層影響數據。這樣state必定程度上是響應式的。
4. 爲了面臨全部可能的擴展問題，最容易想到的辦法就是把全部state集中放到全部組件頂層，而後分發給全部組件。
5. 爲了有更好的state管理，就須要一個庫來做爲更專業的頂層state分發給全部React應用，這就是Redux。讓咱們回來看看重現上面結構的需求：

• 須要回調通知state (等同於回調參數) -> action
• 須要根據回調處理 (等同於父級方法) -> reducer
• 須要state (等同於總狀態) -> store

對Redux來講只有這三個要素：

• action是純聲明式的數據結構，只提供事件的全部要素，不提供邏輯。
• reducer是一個匹配函數，action的發送是全局的：全部的reducer均可以捕捉到並匹配與本身相關與否，相關就拿走action中的要素進行邏輯處理，修改store中的狀態，不相關就不對state作處理原樣返回。
• store負責存儲狀態並能夠被react api回調，發佈action.

固然通常不會直接把兩個庫拿來用，還有一個binding叫react-redux, 提供一個Provider和connect。不少人其實看懂了redux卡在這裏。

• Provider是一個普通組件，能夠做爲頂層app的分發點，它只須要store屬性就能夠了。它會將state分發給全部被connect的組件，無論它在哪裏，被嵌套多少層。

• connect是真正的重點，它是一個科裏化函數，意思是先接受兩個參數（數據綁定mapStateToProps和事件綁定mapDispatchToProps），再接受一個參數（將要綁定的組件自己）。

mapStateToProps：構建好Redux系統的時候，它會被自動初始化，可是你的React組件並不知道它的存在，所以你須要分揀出你須要的Redux狀態，因此你須要綁定一個函數，它的參數是state，簡單返回你關心的幾個值。

mapDispatchToProps：聲明好的action做爲回調，也能夠被注入到組件裏，就是經過這個函數，它的參數是dispatch，經過redux的輔助方法bindActionCreator綁定全部action以及參數的dispatch，就能夠做爲屬性在組件裏面做爲函數簡單使用了，不須要手動dispatch。這個mapDispatchToProps是可選的，若是不傳這個參數redux會簡單把dispatch做爲屬性注入給組件，能夠手動當作store.dispatch使用。這也是爲何要科裏化的緣由。

作好以上流程Redux和React就能夠工做了。簡單地說就是：

1. 頂層分發狀態，讓React組件被動地渲染。
2. 監聽事件，事件有權利回到全部狀態頂層影響狀態。