如何优化 React + Redux 中嵌套组件 props 的小更新?
How to optimize small updates to props of nested component in React + Redux?
示例代码: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/>
没有改变的东西。
添加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 中的 anti-pattern。
更新 1
我遵循了 Dan Abramov 的回答中的建议 normalized my state and 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, Live demo: 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 更新后的回答,我们必须 return connect
的 mapStateToProps
参数 return 一个函数。你可以看看丹的回答。我也更新了 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
刚刚在"connect at every with memorization"
的基础上添加了react-virtualized example
INITIAL: 31.878ms
DISPATCH: 4.549ms
我不确定 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 (right now it’s all nested), you can separate repoIds
from reposById
, and then only have your RepoList
re-render if repoIds
change. This way changes to individual repos won’t affect the list itself, and only the corresponding Repo
will get re-rendered. This pull request might give you an idea of how that could work. The “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
会带来性能损失:每当外部 props 发生变化时,都必须重新计算内部 props。但是使用 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
最后,如果你需要显示这么大量的数据,反正屏幕放不下。在这种情况下,更好的解决方案是使用 virtualized table,这样您就可以呈现数千行,而无需实际显示它们的性能开销。
I got a solution by replacing every tags with an observable inside reducer.
如果它有副作用,它就不是 Redux reducer。它可能有效,但我建议将这样的代码放在 Redux 之外以避免混淆。 Redux reducers 必须是纯函数,并且它们可能不会调用 onNext
主题。
示例代码: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/>
没有改变的东西。
添加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 中的 anti-pattern。
更新 1
我遵循了 Dan Abramov 的回答中的建议 normalized my state and 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, Live demo: 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 更新后的回答,我们必须 return connect
的 mapStateToProps
参数 return 一个函数。你可以看看丹的回答。我也更新了 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
刚刚在"connect at every with memorization"
的基础上添加了react-virtualized exampleINITIAL: 31.878ms
DISPATCH: 4.549ms
我不确定 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 (right now it’s all nested), you can separate repoIds
from reposById
, and then only have your RepoList
re-render if repoIds
change. This way changes to individual repos won’t affect the list itself, and only the corresponding Repo
will get re-rendered. This pull request might give you an idea of how that could work. The “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
会带来性能损失:每当外部 props 发生变化时,都必须重新计算内部 props。但是使用 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
最后,如果你需要显示这么大量的数据,反正屏幕放不下。在这种情况下,更好的解决方案是使用 virtualized table,这样您就可以呈现数千行,而无需实际显示它们的性能开销。
I got a solution by replacing every tags with an observable inside reducer.
如果它有副作用,它就不是 Redux reducer。它可能有效,但我建议将这样的代码放在 Redux 之外以避免混淆。 Redux reducers 必须是纯函数,并且它们可能不会调用 onNext
主题。