如何优化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,调度大约需要200毫秒,这是预料之中的,因为我们浪费了很多时间<Repo/>来分析没有改变的东西.

添加后shouldComponentUpdate,调度大约需要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': {...}
    }
}

我加了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)从哪里来.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);

请注意,我改变了connect()在ConnectedRepo使用一个工厂initialOwnProps,而不是ownProps.这让React Redux跳过所有道具重新评估.

我还删除了不必要shouldComponentUpdate()的<Repo>因为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 Reducer必须是纯函数,并且它们可能不会调用onNext主题.