通俗易懂地理解Redux

前言

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

Redux

從需求出發,看看使用React須要什麼:redux

  1. Reactpropsstate: props意味着父級分發下來的屬性,state意味着組件內部能夠自行管理的狀態,而且整個React沒有數據向上回溯的能力,也就是說數據只能單向向下分發,或者自行內部消化。理解這個是理解ReactRedux的前提。
  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來講只有這三個要素:api

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

固然通常不會直接把兩個庫拿來用,還有一個bindingreact-redux, 提供一個Providerconnect。不少人其實看懂了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

作好以上流程ReduxReact就能夠工做了。簡單地說就是:code

  1. 頂層分發狀態,讓React組件被動地渲染。
  2. 監聽事件,事件有權利回到全部狀態頂層影響狀態。
相關文章
相關標籤/搜索