摘要：異步實戰(zhàn)狀態(tài)管理與組件通信組件通信其他狀態(tài)管理當(dāng)需要改變應(yīng)用的狀態(tài)或有需要更新時，你需要觸發(fā)一個把和載荷封裝成一個。的行為是同步的。所有的狀態(tài)變化必須通過通道。前端路由實現(xiàn)與源碼分析設(shè)計思想應(yīng)用是一個狀態(tài)機，視圖與狀態(tài)是一一對應(yīng)的。

jsx語法糖;cli;state管理;jest單元測試;

webpack-bundle-analyzer

Storybook

查看更多...

用于初始化內(nèi)部狀態(tài)，很少使用；

唯一可以修改state的地方；

使用 this.state 來初始化 state

給事件處理函數(shù)綁定 this

當(dāng)創(chuàng)建時、接收新的 props 時、setState 時、forceUpdate 時會執(zhí)行這個方法

當(dāng)state需要從props初始化時使用；

盡量不要使用：維護兩者狀態(tài)一致性會增加復(fù)雜度；

每次render都會調(diào)用

典型場景;表單控件獲取默認值

UI渲染完成后調(diào)用

只執(zhí)行一次

典型場景：獲取外部資源

組件將要移除時調(diào)用

資源釋放（一些事件監(jiān)聽和定時器需要在此時清除）

在頁面render之前調(diào)用，state已更新

典型場景：獲取render之前的DOM狀態(tài)

組件初始化時不調(diào)用，只有在組件將要更新時才調(diào)用，此時可以修改state

每次UI更新時調(diào)用

典型場景：頁面需要根據(jù)props變化重新獲取數(shù)據(jù)

決定vdom是否要重繪

一般可以由PureComponent自動實現(xiàn)

典型場景：性能優(yōu)化

創(chuàng)建虛擬dom，進行diff算法，更新dom樹都在此進行。此時就不能更改state了。

組件渲染之后調(diào)用，只調(diào)用一次。

就是狀態(tài)機器UI=fn(state) (狀態(tài)分類：domain ui app)

主要應(yīng)用場景在于很多不同層級的組件需要訪問同樣一些的數(shù)據(jù)。如下圖，組件a、組件g、組件f需要共享數(shù)據(jù)，則只需要在最外層套上Provider，需要共享的組件使用Consumer即可。React新Context API在前端狀態(tài)管理的實踐

使用者只需要傳遞子組件，子組件所需要的props在父組件會封裝好，引用子組件的時候就沒必要傳遞所有props了。

高階組件本質(zhì)是一個接受 Component 并返回新的 Component 的函數(shù)。目的是為了復(fù)用通用邏輯 [深入理解 React 高階組件
](https://mp.weixin.qq.com/s?__...

是純 UI 組件，也稱無狀態(tài)組件(SFC:Stateless Functional Component)。渲染所需要的數(shù)據(jù)只通過 props 傳入, 不需要用 class 的方式來創(chuàng)建 React 組件, 也不需要用到 this 關(guān)鍵字，或者用到 state [React中函數(shù)式聲明組件
](https://segmentfault.com/a/11...

給某個組件通過 props 傳遞一個函數(shù)，并且函數(shù)會返回一個 React 組件

提供者模式可以解決非父子組件下的信息傳遞問題, 或者組件層級太深需要層層傳遞的問題

可以讓父組件控制子組件state。render props 可以控制子組件的UI是如何渲染的，state reducer則可以控制子組件的state.

將原來子組件改變state的邏輯移到父組件中，由父組件控制。
異步

組件通信: broadcast dispatch state props context

其他狀態(tài)管理： dva, mobx,flexible,reflux,flummox

action:當(dāng)需要改變應(yīng)用的狀態(tài)或有 View 需要更新時，你需要觸發(fā)一個 Action

action creator:把 type 和 payload（載荷）封裝成一個 Action。type 是你預(yù)定義的多個 type （通常是一個常量列表）之一，代表系統(tǒng)特定的 action。一旦 action 消息創(chuàng)建好了，Action Creator 就會把它傳遞給 Dispatcher

Dispatcher: 它保存著所有需要發(fā)送 action 的 store 列表。當(dāng) Action Creator 給過來一個 action，它會把這個 action 傳遞給各個 store。

waitfor:Dispatcher 的行為是同步的。如果想要在 store 之間實現(xiàn)依賴，有的更新完了其他的才能更新，你可以使用 Dispatcher 提供的 waitFor() 來實現(xiàn)。

store:所有的狀態(tài)變化,必須通過 Action Creator/Dispatcher 通道。使用switch判斷 action 的類型，決定是否相應(yīng)。如果相應(yīng)則根據(jù) action 找出需要變化的部分，更新 state。

observable: 通過 observable(state) 定義組件的狀態(tài)，包裝后的狀態(tài)是一個可觀察數(shù)據(jù)（Observable Data）。

observer: 通過 observer(ReactComponent) 定義組件

action: 通過 action 來修改狀態(tài)。

react-redux 提供了兩個重要的對象，Provider 和 connect，前者使 React 組件可被連接（connectable），后者把 React 組件和 Redux 的 store 真正連接起來。

通過 reducer 創(chuàng)建一個 store，每當(dāng)我們在 store 上 dispatch 一個 action，store 內(nèi)的數(shù)據(jù)就會相應(yīng)地發(fā)生變化。

provider

connect([mapStateToProps], [mapDispatchToProps], [mergeProps], [options])

樹的遞歸

判斷屬性的更改

判斷列表差異算法實現(xiàn) React Diff算法

遍歷子元素打標識

渲染差異

詳情參考 深入框架本源系列 —— Virtual Dom

以 hash 形式（也可以使用 History API 來處理）為例，當(dāng) url 的 hash 發(fā)生變化時，觸發(fā) hashchange 注冊的回調(diào)，回調(diào)中去進行不同的操作，進行不同的內(nèi)容的展示。前端路由實現(xiàn)與 react-router 源碼分析

Web 應(yīng)用是一個狀態(tài)機，視圖與狀態(tài)是一一對應(yīng)的。

所有的狀態(tài)，保存在一個對象里面。

Redux 讓應(yīng)用的狀態(tài)變化變得可預(yù)測。如果想改變應(yīng)用的狀態(tài)，就必須 dispatch 對應(yīng)的 action。而不能直接改變應(yīng)用的狀態(tài)，因為保存這些狀態(tài)的地方（稱為 store）只有 get方法（getState） 而沒有 set方法。

只要Redux 訂閱(subscribe)相應(yīng)框架(例如React)內(nèi)部方法，就可以使用該應(yīng)用框架保證數(shù)據(jù)流動的一致性。

Redux源碼剖析及應(yīng)用

《React源碼解析(一):組件的實現(xiàn)與掛載》
《React源碼解析(二):組件的類型與生命周期》
《React源碼解析(三):詳解事務(wù)與隊列》
《React源碼解析(四):事件系統(tǒng)》
React底層揭秘

《深入淺出React和Redux》程墨
React 狀態(tài)管理庫: Mobx
深入淺出react
React 實踐心得：react-redux 之 connect 方法詳解、
《React實戰(zhàn)進階45講》 王沛 - 極客時間
react 生命周期
重新認識reacrt生命周期
react組件設(shè)計模式快速指南