写在前面
react-redux作为胶水一样的东西,似乎没有深入了解的必要,但实际上,作为数据层(redux)与UI层(react)的连接处,其实现细节对整体性能有着决定性的影响。组件树胡乱update的成本,要比多跑几遍reducer树的成本高得多,所以有必要了解其实现细节
仔细了解react-redux的好处之一是可以对性能有基本的认识,考虑一个问题:
dispatch({type: 'UPDATE_MY_DATA', payload: myData})
组件树中某个角落的这行代码,带来的性能影响是什么?几个子问题:
1.导致哪些reducer被重新计算了?
2.引发的视图更新从哪个组件开始?
3.哪些组件的render被调用了?
4.每个叶子组件都被diff波及了吗?为什么?
如果无法准确回答这几个问题,对性能肯定是心里没底的
一.作用
首先,明确redux只是一个数据层,而react只是一个UI层,二者之间是没有联系的
如果左右手分别拿着redux和react,那么实际情况应该是这样的:
redux把数据结构(state)及各字段的计算方式(reducer)都定好了
react根据视图描述(Component)把初始页面渲染出来
可能是这个样子:
redux | react
myUniversalState | myGreatUI
human | noOneIsHere
soldier |
arm |
littleGirl |
toy |
ape | noOneIsHere
hoho |
tree | someTrees
mountain | someMountains
snow | flyingSnow
左边redux里什么都有,但是react不知道,只显示了默认元素(没有没有数据),有一些组件局部state和零散的props传递,页面就像一帧静态图,组件树看起来只是由一些管道连接起来的大架子
现在我们考虑把react-redux加进来,那么就会变成这样子:
react-redux
redux -+- react
myUniversalState | myGreatUI
HumanContainer
human -+- humans
soldier | soldiers
ArmContainer
arm -+- arm
littleGirl | littleGirl
toy | toy
ApeContainer
ape -+- apes
hoho | hoho
SceneContainer
tree -+- Scene
mountain | someTrees
snow | someMountains
flyingSnow
注意,Arm交互比较复杂,不适合由上层(HumanContainer)控制,所以出现了嵌套Container
Container把redux手里的state交给react,这样初始数据就有了,那么如果要更新视图呢?
Arm.dispatch({type: 'FIRST_BLOOD', payload: warData})
有人打响了第一枪,导致soldier挂了一个(state change),那么这些部分要发生变化:
react-redux
redux -+- react
myNewUniversalState | myUpdatedGreatUI
HumanContainer
human -+- humans
soldier | soldiers
| diedSoldier
ArmContainer
arm -+- arm
| inactiveArm
页面上出现一个挂掉的soldier和一支掉地上的arm(update view),其它部分(ape, scene)一切安好
上面描述的就是react-redux的作用:
把state从redux传递到react
并负责在redux state change后update react view
那么猜也知道,实现分为3部分:
给管道连接起来的大架子添上一个个小水源(通过Container把state作为props注入下方view)
让小水源冒水(监听state change,通过Container的setState来更新下方view)
不小水源不要乱冒(内置性能优化,对比缓存的state, props看有没有必要更新)
二.关键实现
源码关键部分如下:
// from: src/components/connectAdvanced/Connect.onStateChange
onStateChange() {
// state change时重新计算props
this.selector.run(this.props)
// 当前组件不用更新的话,通知下方container检查更新
// 要更新的话,setState空对象强制更新,延后通知到didUpdate
if (!this.selector.shouldComponentUpdate) {
this.notifyNestedSubs()
} else {
this.componentDidUpdate = this.notifyNestedSubsOnComponentDidUpdate
// 通知Container下方的view更新
//!!! 这里是把redux与react连接起来的关键
this.setState(dummyState)
}
}
最重要的那个setState
就在这里,dispatch action后视图更新的秘密是这样:
1.dispatch action
2.redux计算reducer得到newState
3.redux触发state change(调用之前通过store.subscribe注册的state变化监听器)
4.react-redux顶层Container的onStateChange触发
1.重新计算props
2.比较新值和缓存值,看props变了没,要不要更新
3.要的话通过setState({})强制react更新
4.通知下方的subscription,触发下方关注state change的Container的onStateChange,检查是否需要更新view
第3步里,react-redux向redux注册store change监听的动作发生在connect()(myComponent)
时,事实上react-redux只对顶层Container直接监听了redux的state change,下层Container都是内部传递通知的,如下:
// from: src/utils/Subscription/Subscription.trySubscribe
trySubscribe() {
if (!this.unsubscribe) {
// 没有父级观察者的话,直接监听store change
// 有的话,添到父级下面,由父级传递变化
this.unsubscribe = this.parentSub
? this.parentSub.addNestedSub(this.onStateChange)
: this.store.subscribe(this.onStateChange)
}
}
这里不直接监听redux的state change,而非要自己维护Container的state change listener,是为了实现次序可控,例如上面提到的:
// 要更新的话,延后通知到didUpdate
this.componentDidUpdate = this.notifyNestedSubsOnComponentDidUpdate
这样保证了listener触发顺序是按照组件树层级顺序的,先通知大子树更新,大子树更新完毕后,再通知小子树更新
更新的整个过程就是这样,至于“通过Container把state作为props注入下方view”这一步,没什么好说的,如下:
// from: src/components/connectAdvanced/Connect.render
render() {
return createElement(WrappedComponent, this.addExtraProps(selector.props))
}
根据WrappedComponent需要的state字段,造一份props,通过React.createElement
注入进去。ContainerInstance.setState({})
时,这个render
函数被重新调用,新的props被注入到view,view will receive props…视图更新就真正开始了
三.技巧
让纯函数拥有状态
function makeSelectorStateful(sourceSelector, store) {
// wrap the selector in an object that tracks its results between runs.
const selector = {
run: function runComponentSelector(props) {
try {
const nextProps = sourceSelector(store.getState(), props)
if (nextProps !== selector.props || selector.error) {
selector.shouldComponentUpdate = true
selector.props = nextProps
selector.error = null
}
} catch (error) {
selector.shouldComponentUpdate = true
selector.error = error
}
}
}
return selector
}
把纯函数用对象包起来,就可以有局部状态了,作用和new Class Instance类似。这样就把纯的部分与不纯的部分分离开了,纯的依然纯,不纯的在外面,class不如这个干净
默认参数与对象解构
function connectAdvanced(
selectorFactory,
// options object:
{
getDisplayName = name => `ConnectAdvanced(${name})`,
methodName = 'connectAdvanced',
renderCountProp = undefined,
shouldHandleStateChanges = true,
storeKey = 'store',
withRef = false,
// additional options are passed through to the selectorFactory
...connectOptions
} = {}
) {
const selectorFactoryOptions = {
// 展开 还原回去
...connectOptions,
getDisplayName,
methodName,
renderCountProp,
shouldHandleStateChanges,
storeKey,
withRef,
displayName,
wrappedComponentName,
WrappedComponent
}
}
可以简化成这样:
function f({a = 'a', b = 'b', ...others} = {}) {
console.log(a, b, others);
const newOpts = {
...others,
a,
b,
s: 's'
};
console.log(newOpts);
}
// test
f({a: 1, c: 2, f: 0});
// 输出
// 1 "b" {c: 2, f: 0}
// {c: 2, f: 0, a: 1, b: "b", s: "s"}
这里用到3个es6+小技巧:
默认参数。防止解构时右边undefined报错
对象解构。把剩余属性都包进others对象里
展开运算符。把others展开,属性merge到目标对象上
默认参数是es6特性,没什么好说的。对象解构是Stage 3 proposal,...others
是其基本用法。展开运算符把对象展开,merge到目标对象上,也不复杂
比较有意思的是这里把对象解构和展开运算符配合使用,实现了这种需要对参数做打包-还原的场景,如果不用这2个特性,可能需要这样做:
function connectAdvanced(
selectorFactory,
connectOpts,
otherOpts
) {
const selectorFactoryOptions = extend({},
otherOpts,
getDisplayName,
methodName,
renderCountProp,
shouldHandleStateChanges,
storeKey,
withRef,
displayName,
wrappedComponentName,
WrappedComponent
)
}
需要清楚地区分connectOpts
和otherOpts
,实现上会麻烦一些,组合运用这些技巧的话,代码相当简练
另外还有1个es6+小技巧:
addExtraProps(props) {
//! 技巧 浅拷贝保证最少知识
//! 浅拷贝props,不把别人不需要的东西传递出去,否则影响GC
const withExtras = { ...props }
}
多一份引用就多一份内存泄漏的风险,不需要的不应该给(最少知识)
参数模式匹配
function match(arg, factories, name) {
for (let i = factories.length - 1; i >= 0; i--) {
const result = factories[i](arg)
if (result) return result
}
return (dispatch, options) => {
throw new Error(`Invalid value of type ${typeof arg} for ${name} argument when connecting component ${options.wrappedComponentName}.`)
}
}
其中factories
是这样:
// mapDispatchToProps
[
whenMapDispatchToPropsIsFunction,
whenMapDispatchToPropsIsMissing,
whenMapDispatchToPropsIsObject
]
// mapStateToProps
[
whenMapStateToPropsIsFunction,
whenMapStateToPropsIsMissing
]
针对参数的各种情况建立一系列case函数,然后让参数依次流经所有case,匹配任意一个就返回其结果,都不匹配就进入错误case
类似于switch-case,用来对参数做模式匹配,这样各种case都被分解出去了,各自职责明确(各case函数的命名非常准确)
懒参数
function wrapMapToPropsFunc() {
// 猜完立即算一遍props
let props = proxy(stateOrDispatch, ownProps)
// mapToProps支持返回function,再猜一次
if (typeof props === 'function') {
proxy.mapToProps = props
proxy.dependsOnOwnProps = getDependsOnOwnProps(props)
props = proxy(stateOrDispatch, ownProps)
}
}
其中,懒参数是指:
// 把返回值作为参数,再算一遍props
if (typeof props === 'function') {
proxy.mapToProps = props
proxy.dependsOnOwnProps = getDependsOnOwnProps(props)
props = proxy(stateOrDispatch, ownProps)
}
这样实现和react-redux面临的场景有关,支持返回function主要是为了支持组件实例级(默认是组件级)的细粒度mapToProps控制。这样就能针对不同组件实例,给不同的mapToProps,支持进一步提升性能
从实现上来看,相当于把实际参数延后了,支持传入一个参数工厂作为参数,第一次把外部环境传递给工厂,工厂再根据环境造出实际参数。添了工厂这个环节,就把控制粒度细化了一层(组件级的细化到了组件实例级,外部环境即组件实例信息)
P.S.关于懒参数的相关讨论见https://github.com/reactjs/react-redux/pull/279
四.疑问
1.默认的props.dispatch哪里来的?
connect()(MyComponent)
不给connect传任何参数,MyComponent实例也能拿到一个prop叫dispatch
,是在哪里偷偷挂上的?
function whenMapDispatchToPropsIsMissing(mapDispatchToProps) {
return (!mapDispatchToProps)
// 就是这里挂上去的,没传mapDispatchToProps的话,默认把dispatch挂到props上
? wrapMapToPropsConstant(dispatch => ({ dispatch }))
: undefined
}
默认内置了一个mapDispatchToProps = dispatch => ({ dispatch })
,所以组件props身上有dispatch
,如果指定了mapDispatchToProps
,就不给挂了
2.多级Container会不会面临性能问题?
考虑这种场景:
App
HomeContainer
HomePage
HomePageHeader
UserContainer
UserPanel
LoginContainer
LoginButton
出现了嵌套的container,那么在HomeContainer关注的state发生变化时,会不会走很多遍视图更新?比如:
HomeContainer update-didUpdate
UserContainer update-didUpdate
LoginContainer update-didUpdate
如果是这样,轻轻一发dispatch,导致3个子树更新,感觉性能要炸了
实际上不是这样。对于多级Container,走两遍的情况确实存在,只是这里的走两遍不是指视图更新,而是说state change通知
上层Container在didUpdate后会通知下方Container检查更新,可能会在小子树再走一遍。但在大子树更新的过程中,走到下方Container时,小子树在这个时机就开始更新了,大子树didUpdate后的通知只会让下方Container空走一遍检查,不会有实际更新
检查的具体成本是分别对state和props做===
比较和浅层引用比较(也是先===比较),发现没变就结束了,所以每个下层Container的性能成本是两个===
比较,不要紧。也就是说,不用担心使用嵌套Container带来的性能开销
五.源码分析
Github地址:https://github.com/ayqy/react-redux-5.0.6
P.S.注释依然足够详尽。