一直對於redux
處於只知其一;不知其二的狀態,有幸看到Wang Namelos老師在知乎上一段回答,認真讀了三遍,猶如醍醐灌頂,推薦給你們,內容以下:react
從需求出發,看看使用React
須要什麼:redux
React
有props
和state
: props
意味着父級分發下來的屬性,state
意味着組件內部能夠自行管理的狀態,而且整個React
沒有數據向上回溯的能力,也就是說數據只能單向向下分發,或者自行內部消化。理解這個是理解React
和Redux
的前提。React
組件內部多是一個完整的應用,它本身工做良好,你能夠經過屬性做爲API控制它。可是更多的時候發現React
根本沒法讓兩個組件互相交流,使用對方的數據。而後這時候不經過DOM
溝通(也就是React
體制內)解決的惟一辦法就是提高state
,將state
放到共有的父組件中來管理,再做爲props
分發回子組件。state
的辦法只能是經過onClick
觸發父組件聲明好的回調,也就是父組件提早聲明好函數或方法做爲契約描述本身的state
將如何變化,再將它一樣做爲屬性交給子組件使用。這樣就出現了一個模式:數據老是單向從頂層向下分發的,可是隻有子組件回調在概念上能夠回到state
頂層影響數據。這樣state
必定程度上是響應式的。state
集中放到全部組件頂層,而後分發給全部組件。state
管理,就須要一個庫來做爲更專業的頂層state
分發給全部React
應用,這就是Redux
。讓咱們回來看看重現上面結構的需求:state
(等同於回調參數) -> action
reducer
state
(等同於總狀態) -> store
對Redux
來講只有這三個要素:api
action
是純聲明式的數據結構,只提供事件的全部要素,不提供邏輯。reducer
是一個匹配函數,action
的發送是全局的:全部的reducer
均可以捕捉到並匹配與本身相關與否,相關就拿走action
中的要素進行邏輯處理,修改store
中的狀態,不相關就不對state
作處理原樣返回。store
負責存儲狀態並能夠被react api
回調,發佈action
.固然通常不會直接把兩個庫拿來用,還有一個binding
叫react-redux
, 提供一個Provider
和connect
。不少人其實看懂了redux
卡在這裏。數據結構
Provider
是一個普通組件,能夠做爲頂層app
的分發點,它只須要store
屬性就能夠了。它會將state
分發給全部被connect
的組件,無論它在哪裏,被嵌套多少層。app
connect
是真正的重點,它是一個科裏化函數,意思是先接受兩個參數(數據綁定mapStateToProps
和事件綁定mapDispatchToProps
),再接受一個參數(將要綁定的組件自己)。ide
mapStateToProps
:構建好Redux
系統的時候,它會被自動初始化,可是你的React
組件並不知道它的存在,所以你須要分揀出你須要的Redux
狀態,因此你須要綁定一個函數,它的參數是state
,簡單返回你關心的幾個值。函數
mapDispatchToProps
:聲明好的action
做爲回調,也能夠被注入到組件裏,就是經過這個函數,它的參數是dispatch
,經過redux
的輔助方法bindActionCreator
綁定全部action
以及參數的dispatch
,就能夠做爲屬性在組件裏面做爲函數簡單使用了,不須要手動dispatch
。這個mapDispatchToProps
是可選的,若是不傳這個參數redux會簡單把dispatch
做爲屬性注入給組件,能夠手動當作store.dispatch
使用。這也是爲何要科裏化的緣由。spa
作好以上流程Redux
和React
就能夠工做了。簡單地說就是:code
React
組件被動地渲染。