1. 程式人生 > >Redux在處理龐大Store並頻繁進行更新操作時的效能

Redux在處理龐大Store並頻繁進行更新操作時的效能

Q:當你擁有一個相當大的 SPA 擁有許多狀態,因為有很多頁面,模組,子模組和許多元素。所有子狀態都關聯 App 中不同的關注點,子狀態由它們自己的 reducer 處理。但是當進行非常頻繁的更新操作,所有的 reducer 都將被呼叫。

當擁有一個如下的 store:

store: {
  subStore1: {
    subSubstore1: {}
    ...
    subSubstore10: {}
  },
subStore2: {
    subSubstore1: {}
    ...
    subSubstore10: {}
  }
...
subStore10: {
    subSubstore1: {}
    ...
    subSubstore10: {}
  }
}

dispatch 一個更新 substore2: { subStore6 } 的 action。

為什麼不簡單地複製指標 substore1、substore3、... substore9,而現在是呼叫其他子 store 的 reducer?

 

A:可以使用 redux-ignore https://github.com/omnidan/redux-ignore

 

Redux Store 中只有一個 reducer 函式。你可以分解該函式,並根據你的需求來權衡便利、速度或其他因素。combineReducers 是處理此問題的常用方法,但並不是必需的。

 

如何處理那些已訂閱狀態變化的元件?

使用 react-redux。由 React-Redux 的 connect() 函式生成的包裝元件會進行多次檢查,以儘量減少實際元件重渲染(re-render)。這包括 shouldComponentUpdate 的預設實現,並對進入元件的 props 進行淺檢查(包括從 mapStateToProps 返回的內容)。所以一般情況下,被 connect 的元件只有在狀態值發生變化時才會重渲染。

 

參考:https://github.com/reduxjs/redux/issues/1303