React Redux · redux中文文檔

# Redux 常見問題：React Redux ## 目錄 - [為何組件沒有被重新渲染、或者 mapStateToProps 沒有運行？](#react-not-rerendering) - [為何組件頻繁的重新渲染？](#react-rendering-too-often) - [怎樣使 mapStateToProps 執行更快？](#react-mapstate-speed) - [為何不在被連接的組件中使用 this.props.dispatch ？](#react-props-dispatch) - [應該只連接到頂層組件嗎，或者可以在組件樹中連接到不同組件嗎？](#react-multiple-components) ## React Redux <a id="react-not-rerendering"></a> ### 為何組件沒有被重新渲染、或者 mapStateToProps 沒有運行？目前來看，導致組件在 action 分發后卻沒有被重新渲染，最常見的原因是對 state 進行了直接修改。Redux 期望 reducer 以 “不可變的方式” 更新 state，實際使用中則意味著復制數據，然后更新數據副本。如果直接返回同一對象，即使你改變了數據內容，Redux 也會認為沒有變化。類似的，React Redux 會在 `shouldComponentUpdate` 中對新的 props 進行淺層的判等檢查，以期提升性能。如果所有的引用都是相同的，則返回 `false` 從而跳過此次對組件的更新。需要注意的是，不管何時更新了一個嵌套的值，都必須同時返回上層的任何數據副本給 state 樹。如果數據是 `state.a.b.c.d`，你想更新 `d`，你也必須返回 `c`、`b`、`a` 以及 `state` 的拷貝。[state 樹變化圖](http://arqex.com/wp-content/uploads/2015/02/trees.png) 展示了樹的深層變化為何需要改變途經的結點。 “以不可變的方式更新數據” 并 _不_ 代表你必須使用 [Immutable.js](https://facebook.github.io/immutable-js/), 雖然是很好的選擇。你可以使用多種方法，達到對普通 JS 對象進行不可變更新的目的： - 使用類似于 `Object.assign()` 或者 `_.extend()` 的方法復制對象， `slice()` 和 `concat()` 方法復制數組。 - ES6 數組的 spread sperator（展開運算符），JavaScript 新版本提案中類似的對象展開運算符。 - 將不可變更新邏輯包裝成簡單方法的工具庫。 #### 補充資料 **文檔** - [Troubleshooting](Troubleshooting.md) - [React Redux: Troubleshooting](https://github.com/reactjs/react-redux/blob/master/docs/troubleshooting.md) - [Recipes: Using the Object Spread Operator](/docs/recipes/UsingObjectSpreadOperator.md) - [Recipes: Structuring Reducers - Prerequisite Concepts](/docs/recipes/reducers/PrerequisiteConcepts.md) - [Recipes: Structuring Reducers - Immutable Update Patterns](/docs/recipes/reducers/ImmutableUpdatePatterns.md) **文章** - [Pros and Cons of Using Immutability with React](http://reactkungfu.com/2015/08/pros-and-cons-of-using-immutability-with-react-js/) - [React/Redux Links: Immutable Data](https://github.com/markerikson/react-redux-links/blob/master/immutable-data.md) **討論** - [#1262: Immutable data + bad performance](https://github.com/reactjs/redux/issues/1262) - [React Redux #235: Predicate function for updating component](https://github.com/reactjs/react-redux/issues/235) - [React Redux #291: Should mapStateToProps be called every time an action is dispatched？](https://github.com/reactjs/react-redux/issues/291) - [Stack Overflow: Cleaner/shorter way to update nested state in Redux？](http://stackoverflow.com/questions/35592078/cleaner-shorter-way-to-update-nested-state-in-redux) - [Gist: state mutations](https://gist.github.com/amcdnl/7d93c0c67a9a44fe5761#gistcomment-1706579) <a id="react-rendering-too-often"></a> ### 為何組件頻繁的重新渲染？ React Redux 采取了很多的優化手段，保證組件直到必要時才執行重新渲染。一種是對 `mapStateToProps` 和 `mapDispatchToProps` 生成后傳入 `connect` 的 props 對象進行淺層的判等檢查。遺憾的是，如果當 `mapStateToProps` 調用時都生成新的數組或對象實例的話，此種情況下的淺層判等不會起任何作用。一個典型的示例就是通過 ID 數組返回映射的對象引用，如下所示： ```js const mapStateToProps = state => { return { objects: state.objectIds.map(id => state.objects[id]) } } ``` 盡管每次數組內都包含了同樣的對象引用，數組本身卻指向不同的引用，所以淺層判等的檢查結果會導致 React Redux 重新渲染包裝的組件。這種額外的重新渲染也可以避免，使用 reducer 將對象數組保存到 state，利用 [Reselect](https://github.com/reactjs/reselect) 緩存映射的數組，或者在組件的 `shouldComponentUpdate` 方法中，采用 `_.isEqual` 等對 props 進行更深層次的比較。注意在自定義的 `shouldComponentUpdate()` 方法中不要采用了比重新渲染本身更為昂貴的實現。可以使用分析器評估方案的性能。對于獨立的組件，也許你想檢查傳入的 props。一個普遍存在的問題就是在 render 方法中綁定父組件的回調，比如 `<Child onClick={this.handleClick.bind(this)} />`。這樣就會在每次父組件重新渲染時重新生成一個函數的引用。所以只在父組件的構造函數中綁定一次回調是更好的做法。 #### 補充資料 **文檔** - [FAQ: Performance - Scaling](/docs/faq/Performance.md#performance-scaling) **文章** - [A Deep Dive into React Perf Debugging](http://benchling.engineering/deep-dive-react-perf-debugging/) - [React.js pure render performance anti-pattern](https://medium.com/@esamatti/react-js-pure-render-performance-anti-pattern-fb88c101332f) - [Improving React and Redux Performance with Reselect](http://blog.rangle.io/react-and-redux-performance-with-reselect/) - [Encapsulating the Redux State Tree](http://randycoulman.com/blog/2016/09/13/encapsulating-the-redux-state-tree/) - [React/Redux Links: React/Redux Performance](https://github.com/markerikson/react-redux-links/blob/master/react-performance.md) **討論** - [Stack Overflow: Can a React Redux app scale as well as Backbone？](http://stackoverflow.com/questions/34782249/can-a-react-redux-app-really-scale-as-well-as-say-backbone-even-with-reselect) **庫** - [Redux Addons Catalog: DevTools - Component Update Monitoring](https://github.com/markerikson/redux-ecosystem-links/blob/master/devtools.md#component-update-monitoring) <a id="react-mapstate-speed"></a> ### 怎樣使 `mapStateToProps` 執行更快？盡管 React Redux 已經優化并盡量減少對 `mapStateToProps` 的調用次數，加快 `mapStateToProps` 執行并減少其執行次數仍然是非常有價值的。普遍的推薦方式是利用 [Reselect](https://github.com/reactjs/reselect) 創建可記憶（memoized）的 “selector” 方法。這樣，selector 就能被組合在一起，并且同一管道（pipeline）后面的 selector 只有當輸入變化時才會執行。意味著你可以像篩選器或過濾器那樣創建 selector，并確保任務的執行時機。 #### 補充資料 **文檔** - [Recipes: Computed Derived Data](/docs/recipes/ComputingDerivedData.md) **文章** - [Improving React and Redux Performance with Reselect](http://blog.rangle.io/react-and-redux-performance-with-reselect/) **討論** - [#815: Working with Data Structures](https://github.com/reactjs/redux/issues/815) - [Reselect #47: Memoizing Hierarchical Selectors](https://github.com/reactjs/reselect/issues/47) <a id="react-props-dispatch"></a> ### 為何不在被連接的組件中使用 `this.props.dispatch`？ `connect()` 方法有兩個主要的參數，而且都是可選的。第一個參數 `mapStateToProps` 是個函數，讓你在數據變化時從 store 獲取數據，并作為 props 傳到組件中。第二個參數 `mapDispatchToProps` 依然是函數，讓你可以使用 store 的 `dispatch` 方法，通常都是創建 action 創建函數并預先綁定，那么在調用時就能直接分發 action。如果在執行 `connect()` 時沒有指定 `mapDispatchToProps` 方法，React Redux 默認將 `dispatch` 作為 prop 傳入。所以當你指定方法時， `dispatch` 將 _不_ 會自動注入。如果你還想讓其作為 prop，需要在 `mapDispatchToProps` 實現的返回值中明確指出。 #### 補充資料 **文檔** - [React Redux API: connect()](https://github.com/reactjs/react-redux/blob/master/docs/api.md#connectmapstatetoprops-mapdispatchtoprops-mergeprops-options) **討論** - [React Redux #89: can i wrap multi actionCreators into one props with name？](https://github.com/reactjs/react-redux/issues/89) - [React Redux #145: consider always passing down dispatch regardless of what mapDispatchToProps does](https://github.com/reactjs/react-redux/issues/145) - [React Redux #255: this.props.dispatch is undefined if using mapDispatchToProps](https://github.com/reactjs/react-redux/issues/255) - [Stack Overflow: How to get simple dispatch from this.props using connect w/ Redux？](http://stackoverflow.com/questions/34458261/how-to-get-simple-dispatch-from-this-props-using-connect-w-redux/34458710]) <a id="react-multiple-components"></a> ### 應該只連接到頂層組件嗎，或者可以在組件樹中連接到不同組件嗎？早期的 Redux 文檔中建議只在組件樹頂層附近連接若干組件。然而，時間和經驗都表明，這需要讓這些組件非常了解它們子孫組件的數據需求，還導致它們會向下傳遞一些令人困惑的 props。目前的最佳實踐是將組件按照 “展現層（presentational）” 或者 “容器（container）” 分類，并在合理的地方抽象出一個連接的容器組件： > Redux 示例中強調的 “在頂層保持一個容器組件” 是錯誤的。不要把這個當做準則。讓你的展現層組件保持獨立。然后創建容器組件并在合適時進行連接。當你感覺到你是在父組件里通過復制代碼為某些子組件提供數據時，就是時候抽取出一個容器了。只要你認為父組件過多了解子組件的數據或者 action，就可以抽取容器。總之，試著在數據流和組件職責間找到平衡。 #### 補充資料 **文檔** - [Basics: Usage with React](basics/UsageWithReact.md) **文章** - [Presentational and Container Components](https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0) - [High-Performance Redux](http://somebody32.github.io/high-performance-redux/) - [React/Redux Links: Architecture - Redux Architecture](https://github.com/markerikson/react-redux-links/blob/master/react-redux-architecture.md#redux-architecture) - [React/Redux Links: Performance - Redux Performance](https://github.com/markerikson/react-redux-links/blob/master/react-performance.md#redux-performance) **討論** - [Twitter: emphasizing “one container” was a mistake](https://twitter.com/dan_abramov/status/668585589609005056) - [#419: Recommended usage of connect](https://github.com/reactjs/redux/issues/419) - [#756: container vs component？](https://github.com/reactjs/redux/issues/756) - [#1176: Redux+React with only stateless components](https://github.com/reactjs/redux/issues/1176) - [Stack Overflow: can a dumb component use a Redux container？](http://stackoverflow.com/questions/34992247/can-a-dumb-component-use-render-redux-container-component)