内容简介:<!-- TOC --><!-- /TOC -->setState改变状态之后,不会立即更新state值。所以,如果改变state值,react是什么时候进行组件的更新呢?setState()到底做了一些什么呢?
<!-- TOC -->
- Q1--setState改变状态之后,不会立即更新state值
- Q2--在render函数里,无法setState
<!-- /TOC -->
Q1
setState改变状态之后,不会立即更新state值。所以,如果改变state值,react是什么时候进行组件的更新呢?setState()到底做了一些什么呢?
A1
1. react生命周期
2. react更新state具体做了什么
引入一段源码
react中定义的setState方法,定义了两个参数(partialState,callback)。
partialState:新的state值;
callback:回调函数。
getInternalInstanceReadyForUpdate方法的目的是获取当前组件对象,将其赋值给internalInstance变量。接下来判断当前组件对象的state更新队列是否存在,如果存在则将partialState也就是新的state值加入队列;如果不存在,则创建该对象的更新队列。然后进入enqueueUpdate方法。
enqueueCallback也是先获取当前组件对象,如果已经存在其他回调,就加入等待回调队列,如果当前没有回调,就创建等待回调队列。然后进入enqueueUpdate方法。
可以发现,enqueueSetState&enqueueCallback最终都是进入enqueueUpdate方法。下面我们来看看enqueueUpdate方法。
官方注解是:给组件做个标记:需要重新渲染,并且将可选的回调函数添加到函数列表中,这些函数将在重新渲染的时候执行。
我们看一下函数具体做了哪些事。发现这个函数只是做了一个判断:如果batchingStrategy.isBatchingUpdates为false,就执行batchingStrategy.batchedUpdates(enqueueUpdate,component),否则就加入dirtyComponents。
这里提到batchingStrategy,批量更新策略。
批量更新策略是什么呢?看代码发现batchingStrategy批量更新策略只是一个简单的对象,定义了一个 isBatchingUpdates 的布尔值和一个 batchedUpdates 方法。默认isBatchingUpdates(下面称为更新标志)为false,然后会进入batchedUpdates方法,先把更新标志isBatchingUpdates设为true,然后执行transaction.perform(callback),即transaction.perform(enqueueUpdate)。
React内部采用了"状态机"的概念,组件处于不同的状态时,所执行的逻辑也并不相同。以组件更新流程为例,React以事务+状态的形式对组件进行更新。
通过上面的一部分代码,我们发现setState()方法主要是enqueueUpdate()进行状态更新,怎样进行状态更新呢?定义了一个批量更新策略:判断更新标志isBatchingUpdates的值,如果为false,调用batchedUpdates()-->(先把更新标志isBatchingUpdates改为true,然后调用transaction.perform(enqueueUpdate))。如果为true,就把组件加入dirtyComponents数组中。
React内部采用了"状态机"的概念,组件处于不同的状态时,所执行的逻辑也并不相同。以组件更新流程为例,React以事务+状态的形式对组件进行更新,因此接下来我们看看事务的机制。
3. transaction 事务
wrappers (injected at creation time) + + | | +-----------------|--------|--------------+ | v | | | +---------------+ | | | +--| wrapper1 |---|----+ | | | +---------------+ v | | | | +-------------+ | | | | +----| wrapper2 |--------+ | | | | +-------------+ | | | | | | | | | | v v v v | wrapper | +---+ +---+ +---------+ +---+ +---+ | invariants perform(anyMethod) | | | | | | | | | | | | maintained +----------------->|-|---|-|---|-->|anyMethod|---|---|-|---|-|--------> | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +---+ +---+ +---------+ +---+ +---+ | | initialize close | +-----------------------------------------+
这是官方代码的解析图。
可以看出调用函数是perform(anyMethod),然后方法anyMethod被wrapper包裹了,wrapper依次执行了initialize->anyMethod->close
function anyMethod(){ console.log('xx') }; transaction.perform(anyMethod);
代码的执行顺序是
initialize() 输出xx close()
所以这里wrapper是怎样定义的呢?
第二个wrapper比较简单,先来看一下第二个wrapper。
第二个wrapper(RESET_BATCHED_UPDATES)的作用是将更新标志isBatchingUpdates重置为false;我的理解这里是收集完所有要更新的state值,都加入_pendingStateQueue待更新状态队列了,然后组件更新完了之后,将更新标志重置为false,等待下次更新。然后下面来看一下第一个wrapper。
5&f=png&s=54081)
第一个wrapper主要的作用是更新组件,执行了ReactUpdates.flushBatchedUpdates.bind(ReactUpdates)。
可以看到flushBatchedUpdates方法循环遍历所有的dirtyComponents,又通过事务的形式调用runBatchedUpdates方法。
一共做了两件事:
- 一是通过执行updateComponent方法来更新组件
- 二是若setState方法传入了回调函数则将回调函数存入callbackQueue队列。
然后看一下 updateComponent 方法,官方注释是: 更新组件,会调用shouldComponentUpdate,然后调用剩余的生命周期函数,更新DOM结构 。
这里终于更新了组件。看代码会发现在shouldComponentUpdate之前,执行了 _processPendingState 方法,该方法主要对state进行处理:
- 1.如果更新队列为null,那么返回原来的state;
- 2.如果更新队列有一个更新,那么返回更新值;
- 3.如果更新队列有多个更新,那么通过for循环将它们合并;
综上说明了,在一个生命周期内,在componentShouldUpdate执行之前,所有的state变化都会被合并,最后统一处理。
4. 回顾上述问题
综上,
- setState()为啥没有立即更新this.state值呢
- 如果在componentDidMount()中连续多次setState,无法进行state累加呢
- 批量更新策略isBatchingStrategy干了什么,怎么做到更新的呢
那按照上述说的批量更新, 第一次setState -->进入enqueueUpdate()-->此时isBatchingUpdates默认为false-->batchedUpdates(enqueueUpdate,...)-->设置isBatchingUpdates为true;transaction.perform(enqueueUpdates);-->(第一个wrapper:FLUSH_BATCHED_UPDATES)组件更新-->(第二个wrapper:RESET_BATCHED_UPDATES的close方法)设置isBatchingUpdates为false--> 第二次setState -->isBatchingUpdates为false-->..-->组件更新-->isBatchingUpdates恢复为false。
这样和结果不对呀?按上述逻辑的话,岂不是每次setState都会更新this.state的值?
调试代码会发现,原来整个将 React 组件渲染到 DOM 中的过程就处于一个大的 Transaction 中。
在进入生命周期之前,就会调用batchedUpdates(),所以此时isBatchingUpdates已经修改为true了。后面第一次进入setState()时,就会进入加入dirtyComponent中。所以这也就是为什么两次打印 this.state.foods 都是 '' 的原因,新的 state 还没有被应用到组件中。
5. 总结
- setState(partialState, callback),不会立即更新state值,要合并所有的state变化后,然后重新渲染的时候,state值才会更新。
- setState(partialState, callback): callback会在所有状态更新之后再调用(demo中state的foods&drinks全部更新之后才会调用)
- 事务这么有用,那我们可以调用事务吗?答案是不可以。
- 另外在componentWillMount里面setState()不会触发重新渲染
Q2
在render函数里,无法setState
A2
在render函数中不能setState()。
从react生命周期可以看出:state更新会重新触发render(),所以会导致setState()-->re-render()-->setState()--re-render()-->...-->setState()-->re-render(),一直循环往复。
所以,同理在state更新的生命周期的函数中(componentWillUpdate/componentDidUpdate),都不能setState()
参考资料
https://juejin.im/post/59cc4c...
https://zh-hans.reactjs.org/d...
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:- 深入理解 FilterChainProxy【源码篇】
- 深入理解 WebSecurityConfigurerAdapter【源码篇】
- 深入理解channel:设计+源码
- 对于Express源码的一些理解
- 深入理解Eureka之源码解析
- 从源码角度深入理解Glide(下)
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
算法设计与应用
迈克尔 T. 古德里奇(Michael T. Goodrich)、罗伯特·塔马契亚(Roberto Tamas / 乔海燕、李悫炜、王烁程 / 机械工业出版社 / 2017-11-20 / CNY 139.00
本书全面系统地介绍算法设计和算法应用的各个领域,内容涵盖经典数据结构、经典算法、算法分析方法、算法设计方法以及算法在各个领域的应用,还包含一些高级主题。本书采用应用驱动的方法引入各章内容,内容编排清晰合理,讲解由浅入深。此外,各章都附有巩固练习、创新练习和应用练习三种类型的题目,为读者理解和掌握算法设计和应用提供了很好的素材。 本书可作为高等院校计算机及相关专业“数据结构和算法”课程的本科生......一起来看看 《算法设计与应用》 这本书的介绍吧!