最近公司比较忙,所以更新进度比较慢,一是因为要梳理以前的代码,二是因为赶进度!!!
这个问题也是机缘巧合碰到了,正赶上这周公司网络无缘无故抽风(很慢),然后那天在调试代码的时候忽然发现浏览器报了一个这样的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机制的(是否立即生效),有兴趣的同学可以查看下资料.