javascript - 如何优化 React + Redux 中嵌套组件 props 的小更新？

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

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

我有上面的组件，Repo 和 RepoList。我想更新第一个 repo ( Line 14 ) 的标签。所以我派了一个UPDATE_TAG行动。在我实现之前 shouldComponentUpdate ，调度大约需要 200 毫秒，这是预期的，因为我们浪费了很多时间 diffing <Repo/>没有改变。

添加后shouldComponentUpdate , dispatch 大约需要 30ms。在生产构建 React.js 后，更新仅花费大约 17 毫秒。这好多了，但是 Chrome 开发控制台中的时间线 View 仍然指示卡顿帧(长于 16.6 毫秒)。

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

我的问题是，对于嵌套组件的 props 如此小的更新，是否有更有效和规范的方式来更新内容？我还能使用 Redux 吗？

我通过替换每个 tags 得到了解决方案带有一个可观察的内部 reducer 。有点像

// 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 的开发构建，每次分派(dispatch)也只需 5 毫秒。但我觉得这是 Redux 中的反模式。

更新1

我遵循了 Dan Abramov 的回答和 normalized my state 中的建议和 updated connect components

新的状态形状是:

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

我添加了 console.time周围ReactDOM.render到时间the initial rendering .

但是，性能比以前差(初始渲染和更新)。 (来源: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 arguments 返回一个函数。你可以看看丹的回答。我也更新了the demos .

下面，我的电脑上的性能要好得多。只是为了好玩，我还在我谈到的 reducer 方法中添加了副作用(source，demo)(请不要使用它，它仅用于实验)。

// 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

刚刚添加 react-virtualized example基于“每次连接内存”

INITIAL: 31.878ms
DISPATCH: 4.549ms

Answer 1

我不确定在哪里const App = connect((state) => state)(RepoList)来自。
corresponding example in React Redux docs has a notice :

Don’t do this! It kills any performance optimizations because TodoApp will rerender after every action. It’s better to have more granular connect() on several components in your view hierarchy that each only listen to a relevant slice of the state.

我们不建议使用这种模式。相反，每个连接 <Repo>具体来说，它会在其 mapStateToProps 中读取自己的数据。 . “tree-view ” 示例显示了如何执行此操作。

如果使状态形状更多normalized (现在都是嵌套的)，可以分开repoIds来自 reposById , 然后只有你的 RepoList如果 repoIds 则重新渲染改变。这样，对单个 repo 的更改不会影响列表本身，只会影响相应的 Repo。将被重新渲染。 This pull request可能会让您了解它是如何工作的。 “real-world ” 示例展示了如何编写处理规范化数据的缩减器。

请注意，为了真正受益于规范化树所提供的性能，您需要完全像 this pull request 那样做做并通过 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伴随着性能损失:只要外部 Prop 发生变化，内部 Prop 就必须重新计算。但是使用 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);

请注意，我更改了 connect()在ConnectedRepo使用带有 initialOwnProps 的工厂而不是 ownProps .这让 React Redux 跳过所有的 prop 重新评估。

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

在我的测试中，这种方法优于之前的两种方法:

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

最后，如果你需要显示如此大量的数据，它无论如何也放不下屏幕。在这种情况下，更好的解决方案是使用 virtualized table因此您可以呈现数千行，而不会产生实际显示它们的性能开销。

---

I got a solution by replacing every tags with an observable inside reducer.

如果它有副作用，它就不是 Redux reducer。它可能有效，但我建议将这样的代码放在 Redux 之外以避免混淆。 Redux reducers 必须是纯函数，它们不能调用 onNext关于主题。