最近公司比较忙,所以更新进度比较慢,一是因为要梳理以前的代码,二是因为赶进度!!!
这个问题也是机缘巧合碰到了,正赶上这周公司网络无缘无故抽风(很慢),然后那天在调试代码的时候忽然发现浏览器报了一个这样的Warning:
warn.png
其实从字面上也大概可以了解个大概,是由于setState只能更新挂载完成的组件或者正在挂载的组件,那么定位这个BUG的第一步当然是先了解组件的生命周期
生命周期
之前我的一片文章其实已经浅略的介绍了下生命周期,这里在补充下,facebook官方把生命周期分为三类,每类对应的函数分别如下:
Mounting:
constructor()
componentWillMount()
render()
componentDidMount()
Updating:
componentWillReceiveProps()
shouldComponentUpdate()
componentWillUpdate()
render()
componentDidUpdate()
Unmounting:
componentWillUnmount()
其中这三大类对应的函数中带有Will的会在render之前调用,带有Did的会在render之后调用,这里着重强调一下shouldComponentUpdate()这个生命周期,因为这个生命周期的返回值将会影响其他生命周期是否执行,其中最值得关注的就是当返回flase的时候不会触发render(另外还有componentWillUpdate() componentDidUpdate()),所以这也就给了我们优化项目的空间.由于题目的报错是指我在Unmounting的时候调用了setState,所以我去排查项目,以为自己手滑写错了......但是结果我排查的时候发现我代码中并没有在componentWillUnmount()这个生命周期钩子里面做setState的逻辑,于是好奇心之下我就在每个生命周期钩子中都用了下setState,于是发现了一些有意思的事
有意思的事
code.png
console.png
这是在componetWillUpdate钩子中写了setState之后的效果,当receive的时候就会无限触发componetWillUpdate,这是为什么呢? 经过程序媛的帮助 @眼角浅蓝(链接在后面)http://www.jianshu.com/u/8385c9b70d89,加上自己翻看源码,大概理解如下:
React源码中有这样一个函数:
performUpdateIfNecessary.png
这个函数负责update组件,我们可以看到当this._pendingStateQueue !=null 时会触发this.updateComponent, this.updateComponent函数的代码如下:
updateComponent: function(
transaction,
prevParentElement,
nextParentElement,
prevUnmaskedContext,
nextUnmaskedContext,
) {
var inst = this._instance;
invariant(
inst != null,
'Attempted to update component `%s` that has already been unmounted ' +
'(or failed to mount).',
this.getName() || 'ReactCompositeComponent',
);
var willReceive = false;
var nextContext;
// Determine if the context has changed or not
if (this._context === nextUnmaskedContext) {
nextContext = inst.context;
} else {
nextContext = this._processContext(nextUnmaskedContext);
willReceive = true;
}
var prevProps = prevParentElement.props;
var nextProps = nextParentElement.props;
// Not a simple state update but a props update
if (prevParentElement !== nextParentElement) {
willReceive = true;
}
// An update here will schedule an update but immediately set
// _pendingStateQueue which will ensure that any state updates gets
// immediately reconciled instead of waiting for the next batch.
if (willReceive && inst.componentWillReceiveProps) {
if (__DEV__) {
measureLifeCyclePerf(
() => inst.componentWillReceiveProps(nextProps, nextContext),
this._debugID,
'componentWillReceiveProps',
);
} else {
inst.componentWillReceiveProps(nextProps, nextContext);
}
}
var nextState = this._processPendingState(nextProps, nextContext);
var shouldUpdate = true;
if (!this._pendingForceUpdate) {
if (inst.shouldComponentUpdate) {
if (__DEV__) {
shouldUpdate = measureLifeCyclePerf(
() => inst.shouldComponentUpdate(nextProps, nextState, nextContext),
this._debugID,
'shouldComponentUpdate',
);
} else {
shouldUpdate = inst.shouldComponentUpdate(
nextProps,
nextState,
nextContext,
);
}
} else {
if (this._compositeType === CompositeTypes.PureClass) {
shouldUpdate =
!shallowEqual(prevProps, nextProps) ||
!shallowEqual(inst.state, nextState);
}
}
}
if (__DEV__) {
warning(
shouldUpdate !== undefined,
'%s.shouldComponentUpdate(): Returned undefined instead of a ' +
'boolean value. Make sure to return true or false.',
this.getName() || 'ReactCompositeComponent',
);
}
this._updateBatchNumber = null;
if (shouldUpdate) {
this._pendingForceUpdate = false;
// Will set `this.props`, `this.state` and `this.context`.
this._performComponentUpdate(
nextParentElement,
nextProps,
nextState,
nextContext,
transaction,
nextUnmaskedContext,
);
} else {
// If it's determined that a component should not update, we still want
// to set props and state but we shortcut the rest of the update.
this._currentElement = nextParentElement;
this._context = nextUnmaskedContext;
inst.props = nextProps;
inst.state = nextState;
inst.context = nextContext;
}
},
程序的最后几行我们可以知道当需要shouldUpdate的时候会执行this._performComponentUpdate这个函数,this._performComponentUpdate函数的源码如下:
_performComponentUpdate.png
我们可以发现这个方法在次调用了componentWillUpdate方法,但是当在componentWillUpdate周期中调用setState时就会触发最上边的performUpdateIfNecessary函数,所以一直循环下去...
附一个生命周期执行顺序的图:
lifeCycle.png
这里通过源码在附一张生命周期是否可以写setState函数的图(这里的可以不可以不是指报错,而是指是否有必要或者是避免出现无限循环):
image.png
es6语法中getDefaultProps和getInitialState合并到构造器constrator中.
回到主题
感觉扯着扯着有点远了,那么这个bug怎么解决呢(我们暂且成为bug,其实不会影响程序运行),到底是怎么产生的呢,原来是因为我有一部分setState写在了fetch的回调函数里,但fetch还没结束时我已经卸载了这个组件,当请求结束后setState执行的时候会发现这个组件已经卸载了,所以才会报了这个warning...
解决办法
1.把所有类似这种的请求放在项目中那个永远不会卸载的组件里,比如最顶层组件,然后数据通过props分发传递,这也就是同样的逻辑为什么通过redux的dispatch不会报warning,因为redux其实就一个最顶层的state,然后组件通过connect把值与props相关联起来
2.第一种方法很麻烦,我现在采用的也是第二种,这里要提一下,其实react早就知道这个问题了,所以在最开始版本有这样一个参数叫isMounted,大家可以打印一下组件里的this,就应该能看的到,与这个一起的还有一个参数叫做replaceState,isMounted这个函数返回true和false,代表组件是否已经卸载,有了这个参数之后我们就可以在fecth的回调函数里在添加一个判断,只有组件未卸载才触发 setState,但是很不巧,这两个api都被废弃了,所以现在我们就只能自己模拟一个这样的函数,自定义个属性,默认为false,然后在componentWillUnmount生命周期中把这个属性制为true,用法和isMounted一样...
题外话
react除了废弃这两个api之外,还有一个很有意思的接口,叫batchedUpdates,这个api主要是控制setState机制的(是否立即生效),有兴趣的同学可以查看下资料.
网友评论