如何优化React + Redux中嵌套组件的道具的小更新？

Question

示例代码： https ： //github.com/d6u/example-redux-update-nested-props/blob/master/one-connect/index.js

观看现场演示： http ： //d6u.github.io/example-redux-update-nested-props/one-connect.html

如何优化嵌套组件的道具的小更新？

我有上面的组件，Repo和RepoList。 我想更新第一个仓库的标签（ 第14行 ）。 所以我发送了一个UPDATE_TAG动作。 在我实现shouldComponentUpdate之前，调度大约需要shouldComponentUpdate毫秒，这是预期的，因为我们浪费了大量时间来区分没有改变的<Repo/> 。

添加了shouldComponentUpdate ，dispatch大约需要30ms。 在生产构建React.js之后，更新仅花费大约17ms。 这要好得多，但Chrome开发者控制台中的时间线视图仍然表示jank帧（超过16.6ms）。

想象一下，如果我们有这样的许多更新，或者<Repo/>比当前更复杂，我们将无法维持60fps。

我的问题是，对于嵌套组件的道具的这种小更新，是否有更高效和规范的方式来更新内容？ 我还可以使用Redux吗？

通过用可观察的内部减速器替换每个tags ，我得到了一个解决方案。 就像是

// inside reducer when handling UPDATE_TAG action
// repos[0].tags of state is already replaced with a Rx.BehaviorSubject
get('repos[0].tags', state).onNext([{
  id: 213,
  text: 'Node.js'
}]);

然后我使用https://github.com/jayphelps/react-observable-subscribe在Repo组件中订阅它们的值。 这很有效。 即使使用React.js的开发构建，每个调度仅花费5ms。 但我觉得这是Redux中的反模式。

更新1

我按照Dan Abramov的回答中的建议， 将我的状态和更新的连接组件 规范化

新的状态形状是：

{
    repoIds: ['1', '2', '3', ...],
    reposById: {
        '1': {...},
        '2': {...}
    }
}

我在ReactDOM.render周围添加了console.time来ReactDOM.render 初始渲染时间。

但是，性能比以前更差（初始渲染和更新）。 （来源： https ： //github.com/d6u/example-redux-update-nested-props/blob/master/repo-connect/index.js ，现场演示： http ： //d6u.github.io/example- redux-update-nested-props / repo-connect.html ）

// With dev build
INITIAL: 520.208ms
DISPATCH: 40.782ms

// With prod build
INITIAL: 138.872ms
DISPATCH: 23.054ms

我认为每个<Repo/>上的连接都有很多开销。

更新2

根据Dan的更新答案，我们必须返回connect的mapStateToProps参数，而不是返回一个函数。 你可以查看Dan的答案。 我还更新了演示 。

下面，我的电脑性能要好得多。 而且为了好玩，我还添加了我所谈到的减速器方法的副作用（ 来源 ， 演示 ）（ 严重的是不使用它，它仅用于实验 ）。

// in prod build (not average, very small sample)

// one connect at root
INITIAL: 83.789ms
DISPATCH: 17.332ms

// connect at every <Repo/>
INITIAL: 126.557ms
DISPATCH: 22.573ms

// connect at every <Repo/> with memorization
INITIAL: 125.115ms
DISPATCH: 9.784ms

// observables + side effect in reducers (don't use!)
INITIAL: 163.923ms
DISPATCH: 4.383ms

更新3

刚刚添加了基于“每次记忆连接”的反应虚拟化示例

INITIAL: 31.878ms
DISPATCH: 4.549ms

Answer 1

我不确定const App = connect((state) => state)(RepoList)来自const App = connect((state) => state)(RepoList) 。
React Redux文档中的相应示例有一个通知 ：

不要这样做！ 它会杀死任何性能优化，因为TodoApp会在每次操作后重新渲染。 最好在视图层次结构中的几个组件上使用更细粒度的connect（），每个组件只监听状态的相关片段。

我们不建议使用此模式。 相反，每个都特别连接<Repo>因此它在mapStateToProps读取自己的数据。 “ 树视图 ”示例显示了如何执行此操作。

如果您的状态造型比较标准化 （现在它所有嵌套），可以单独repoIds从reposById ，然后只有你RepoList如果重新渲染repoIds变化。 这种方式更改为单个repos不会影响列表本身，只会重新呈现相应的Repo 。 这个拉取请求可能会让您了解它是如何工作的。 “ 真实世界 ”示例显示了如何编写处理规范化数据的Reducer。

请注意，为了真正从规范化树所提供的性能中获益，您需要执行与此拉取请求完全相同的操作，并将mapStateToProps()工厂传递给connect() ：

const makeMapStateToProps = (initialState, initialOwnProps) => {
  const { id } = initialOwnProps
  const mapStateToProps = (state) => {
    const { todos } = state
    const todo = todos.byId[id]
    return {
      todo
    }
  }
  return mapStateToProps
}

export default connect(
  makeMapStateToProps
)(TodoItem)

这很重要的原因是因为我们知道ID永远不会改变。 使用ownProps会带来性能损失：内部道具必须在外部道具改变时重新计算。 但是，使用initialOwnProps不会产生这种惩罚，因为它只使用一次。

您的示例的快速版本将如下所示：

import React from 'react';
import ReactDOM from 'react-dom';
import {createStore} from 'redux';
import {Provider, connect} from 'react-redux';
import set from 'lodash/fp/set';
import pipe from 'lodash/fp/pipe';
import groupBy from 'lodash/fp/groupBy';
import mapValues from 'lodash/fp/mapValues';

const UPDATE_TAG = 'UPDATE_TAG';

const reposById = pipe(
  groupBy('id'),
  mapValues(repos => repos[0])
)(require('json!../repos.json'));

const repoIds = Object.keys(reposById);

const store = createStore((state = {repoIds, reposById}, action) => {
  switch (action.type) {
  case UPDATE_TAG:
    return set('reposById.1.tags[0]', {id: 213, text: 'Node.js'}, state);
  default:
    return state;
  }
});

const Repo  = ({repo}) => {
  const [authorName, repoName] = repo.full_name.split('/');
  return (
    <li className="repo-item">
      <div className="repo-full-name">
        <span className="repo-name">{repoName}</span>
        <span className="repo-author-name"> / {authorName}</span>
      </div>
      <ol className="repo-tags">
        {repo.tags.map((tag) => <li className="repo-tag-item" key={tag.id}>{tag.text}</li>)}
      </ol>
      <div className="repo-desc">{repo.description}</div>
    </li>
  );
}

const ConnectedRepo = connect(
  (initialState, initialOwnProps) => (state) => ({
    repo: state.reposById[initialOwnProps.repoId]
  })
)(Repo);

const RepoList = ({repoIds}) => {
  return <ol className="repos">{repoIds.map((id) => <ConnectedRepo repoId={id} key={id}/>)}</ol>;
};

const App = connect(
  (state) => ({repoIds: state.repoIds})
)(RepoList);

console.time('INITIAL');
ReactDOM.render(
  <Provider store={store}>
    <App/>
  </Provider>,
  document.getElementById('app')
);
console.timeEnd('INITIAL');

setTimeout(() => {
  console.time('DISPATCH');
  store.dispatch({
    type: UPDATE_TAG
  });
  console.timeEnd('DISPATCH');
}, 1000);

请注意，我更改了ConnectedRepo connect()以使用具有initialOwnProps而非ownProps的工厂。 这让React Redux跳过所有道具重新评估。

我还删除了<Repo>上不必要的shouldComponentUpdate() ，因为React Redux负责在connect()中实现它。

这种方法在我的测试中胜过以前的两种方法：

one-connect.js: 43.272ms
repo-connect.js before changes: 61.781ms
repo-connect.js after changes: 19.954ms

最后，如果你需要显示如此大量的数据，它无论如何都无法放入屏幕。 在这种情况下，更好的解决方案是使用虚拟化表，以便您可以渲染数千行而不会实际显示它们的性能开销。

---

通过用可观察的内部减速器替换每个标签，我得到了一个解决方案。

如果它有副作用，它不是Redux减速器。 它可能有用，但我建议在Redux之外放置这样的代码以避免混淆。 Redux onNext必须是纯函数，并且它们可能不会在主题上调用onNext 。