写在前面
react-redux作为胶水一样的东西，似乎没有深入了解的必要，但实际上，作为数据层（redux）与UI层（react）的连接处，其实现细节对整体性能有着决定性的影响。组件树胡乱update的成本，要比多跑几遍reducer树的成本高得多，所以有必要了解其实现细节
仔细了解react-redux的好处之一是可以对性能有基本的认识，考虑一个问题：
代码语言：javascript复制dispatch({type: 'UPDATE_MY_DATA', payload: myData})组件树中某个角落的这行代码，带来的性能影响是什么？几个子问题：
- 1.导致哪些reducer被重新计算了？
- 2.引发的视图更新从哪个组件开始？
- 3.哪些组件的render被调用了？
- 4.每个叶子组件都被diff波及了吗？为什么？
如果无法准确回答这几个问题，对性能肯定是心里没底的
一.作用
首先，明确redux只是一个数据层，而react只是一个UI层，二者之间是没有联系的
如果左右手分别拿着redux和react，那么实际情况应该是这样的：
- redux把数据结构（state）及各字段的计算方式（reducer）都定好了
- react根据视图描述（Component）把初始页面渲染出来
可能是这个样子：
代码语言：javascript复制 redux | reactmyUniversalState | myGreatUI
human | noOneIsHere
soldier |
arm |
littleGirl |
toy |
ape | noOneIsHere
hoho |
tree | someTrees
mountain | someMountains
snow | flyingSnow左边redux里什么都有，但是react不知道，只显示了默认元素（没有没有数据），有一些组件局部state和零散的props传递，页面就像一帧静态图，组件树看起来只是由一些管道连接起来的大架子
现在我们考虑把react-redux加进来，那么就会变成这样子：
代码语言：javascript复制 react-redux
redux - - reactmyUniversalState | 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，这样初始数据就有了，那么如果要更新视图呢？
代码语言：javascript复制Arm.dispatch({type: 'FIRST_BLOOD', payload: warData})有人打响了第一枪，导致soldier挂了一个（state change），那么这些部分要发生变化：
代码语言：javascript复制 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看有没有必要更新）
二.关键实现
源码关键部分如下：
代码语言：javascript复制// 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，是为了实现次序可控，例如上面提到的：
代码语言：javascript复制// 要更新的话，延后通知到didUpdate
this.componentDidUpdate = this.notifyNestedSubsOnComponentDidUpdate这样保证了listener触发顺序是按照组件树层级顺序的，先通知大子树更新，大子树更新完毕后，再通知小子树更新
更新的整个过程就是这样，至于“通过Container把state作为props注入下方view”这一步，没什么好说的，如下：
代码语言：javascript复制// 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…视图更新就真正开始了
三.技巧
让纯函数拥有状态
代码语言：javascript复制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不如这个干净
默认参数与对象解构
代码语言：javascript复制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
}
}可以简化成这样：
代码语言：javascript复制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个特性，可能需要这样做：
代码语言：javascript复制function connectAdvanced(
selectorFactory,
connectOpts,
otherOpts
) {
const selectorFactoryOptions = extend({},
otherOpts,
getDisplayName,
methodName,
renderCountProp,
shouldHandleStateChanges,
storeKey,
withRef,
displayName,
wrappedComponentName,
WrappedComponent
)
}需要清楚地区分connectOpts和otherOpts，实现上会麻烦一些，组合运用这些技巧的话，代码相当简练
另外还有1个es6 小技巧：
代码语言：javascript复制addExtraProps(props) {
//! 技巧 浅拷贝保证最少知识
//! 浅拷贝props，不把别人不需要的东西传递出去，否则影响GC
const withExtras = { ...props }
}多一份引用就多一份内存泄漏的风险，不需要的不应该给（最少知识）
参数模式匹配
代码语言：javascript复制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函数的命名非常准确）
懒参数
代码语言：javascript复制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)
}
}其中，懒参数是指：
代码语言：javascript复制// 把返回值作为参数，再算一遍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哪里来的？
代码语言：javascript复制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会不会面临性能问题？
考虑这种场景：
代码语言：javascript复制App
HomeContainer
HomePage
HomePageHeader
UserContainer
UserPanel
LoginContainer
LoginButton出现了嵌套的container，那么在HomeContainer关注的state发生变化时，会不会走很多遍视图更新？比如：
代码语言：javascript复制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.注释依然足够详尽。
