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

Posted 2023-02-22

【中文标题】如何优化 React + Redux 中嵌套组件 props 的小更新？

【英文标题】：How to optimize small updates to props of nested component in React + Redux?

【发布时间】：2016-09-12 20:42:04

【问题描述】：

示例代码：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 毫秒，这是意料之中的，因为我们浪费了很多时间来区分没有改变的 <Repo/>s。

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

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

我的问题是，对于嵌套组件的 props 进行如此小的更新，是否有更有效和规范的方式来更新内容？我还能使用 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 的开发版本，每次调度也只需 5 毫秒。但我觉得这是 Redux 中的一种反模式。

更新 1

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

新的状态形状是：

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

我在ReactDOM.render 周围添加了console.time 到时间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 参数，而不是返回一个函数。你可以看看丹的答案。我还更新了the demos。

下面，我的电脑上的性能要好得多。而且只是为了好玩，我还在我谈到的减速器方法中添加了副作用（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

【问题讨论】：

我修改了答案。

示例链接已失效：/

【参考方案1】：

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

不要这样做！它会扼杀任何性能优化，因为 TodoApp 将在每次操作后重新渲染。 最好在视图层次结构中的多个组件上使用更细粒度的 connect() 收听状态的相关部分。

我们不建议使用这种模式。相反，每个都专门连接<Repo>，以便它在其mapStateToProps 中读取自己的数据。 “tree-view”示例展示了如何做到这一点。

如果你让状态形状更normalized（现在都是嵌套的），你可以将repoIds与reposById分开，然后只有RepoList在repoIds发生变化时重新渲染。这种方式对单个 repos 的更改不会影响列表本身，并且只会重新渲染相应的 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 会带来性能损失：每当外部道具发生变化时，都必须重新计算内部道具。但是使用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 跳过所有的 prop 重新评估。

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

这种方法在我的测试中击败了之前的两种方法：

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

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

---

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

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

【讨论】：

只是想澄清connect((state) => state)(RepoList)的用法。这里我在状态树中只有repos，所以不会有问题。但是，是的，如果状态树更复杂，这将降低性能。

所以等一下，“使用”initialOwnProps，我只需要确保第一个 arg 到 connect() 是一个函数，它返回一个返回 props 对象的函数，而不仅仅是一个返回道具对象直接？而这一切都是在第一次调用时懒惰地确定的？

谢谢，你的回答解决了我的问题。我还用新的演示更新了问题（更新 2）。

@AttilaSzeremi 这是对的。这个 API 的最初动机是拥有per-instance memoization，但结果证明它对这种情况也很有用。