深入理解setState(2)，vue前端开发

最新推荐文章于 2024-09-11 15:11:29 发布

2301_82244182

最新推荐文章于 2024-09-11 15:11:29 发布

阅读量860

点赞数 19

分类专栏：程序员文章标签： vue.js 前端 javascript

本文链接：https://blog.csdn.net/2301_82244182/article/details/137424830

版权

程序员专栏收录该内容

377 篇文章 0 订阅

订阅专栏

本文分析了React中setState在不同场景下的行为差异，如合成事件中的异步性、生命周期函数和原生事件中的同步更新，以及批量更新的工作原理，揭示了eventloop在其中的作用。

摘要由CSDN通过智能技术生成

}

// TODO: Get rid of Sync and use current time?

if (expirationTime === Sync) {

performSyncWork();

} else {

scheduleCallbackWithExpiration(expirationTime);

}

在 requestWork 中有三个if分支，三个分支中有两个方法 performWorkOnRoot 和 performSyncWork ，就是我们默认的update函数，但是在合成事件中，走的是第二个if分支，第二个分支中有两个标识 isBatchingUpdates 和 isUnbatchingUpdates 两个初始值都为 false ，但是在 interactiveUpdates$1 中会把 isBatchingUpdates 设为 true ，下面就是 interactiveUpdates$1 的代码：

function interactiveUpdates$1(fn, a, b) {

if (isBatchingInteractiveUpdates) {

return fn(a, b);

}

// If there are any pending interactive updates, synchronously flush them.

// This needs to happen before we read any handlers, because the effect of

// the previous event may influence which handlers are called during

// this event.

if (!isBatchingUpdates && !isRendering && lowestPendingInteractiveExpirationTime !== NoWork) {

// Synchronously flush pending interactive updates.

performWork(lowestPendingInteractiveExpirationTime, false, null);

lowestPendingInteractiveExpirationTime = NoWork;

}

var previousIsBatchingInteractiveUpdates = isBatchingInteractiveUpdates;

var previousIsBatchingUpdates = isBatchingUpdates;

isBatchingInteractiveUpdates = true;

isBatchingUpdates = true; // 把requestWork中的isBatchingUpdates标识改为true

try {

return fn(a, b);

} finally {

isBatchingInteractiveUpdates = previousIsBatchingInteractiveUpdates;

isBatchingUpdates = previousIsBatchingUpdates;

if (!isBatchingUpdates && !isRendering) {

performSyncWork();

}

在这个方法中把 isBatchingUpdates 设为了 true ,导致在 requestWork 方法中， isBatchingUpdates 为 true ，但是 isUnbatchingUpdates 是 false ，而被直接return了。

那return完的逻辑回到哪里呢，最终正是回到了 interactiveUpdates 这个方法，仔细看一眼，这个方法里面有个try finally语法，前端同学这个其实是用的比较少的，简单的说就是会先执行 try 代码块中的语句，然后再执行 finally 中的代码，而 fn(a, b) 是在try代码块中，刚才说到在 requestWork 中被return掉的也就是这个fn（上文提到的从dispatchEvent 到 requestWork 的一整个调用栈）。

所以当你在 increment 中调用 setState 之后去console.log的时候，是属于 try 代码块中的执行，但是由于是合成事件，try代码块执行完state并没有更新，所以你输入的结果是更新前的 state 值，这就导致了所谓的"异步"，但是当你的try代码块执行完的时候（也就是你的increment合成事件），这个时候会去执行 finally 里的代码，在 finally 中执行了 performSyncWork 方法，这个时候才会去更新你的 state 并且渲染到UI上。

二、生命周期函数中的setState

class App extends Component {

state = { val: 0 }

componentDidMount() {

this.setState({ val: this.state.val + 1 })

console.log(this.state.val) // 输出的还是更新前的值 --> 0

}

render() {

return (

{Counter is: ${this.state.val}}

)

}

钩子函数中setState的调用栈：

其实还是和合成事件一样，当 componentDidmount 执行的时候，react内部并没有更新，执行完componentDidmount 后才去 commitUpdateQueue 更新。这就导致你在 componentDidmount 中 setState 完去console.log拿的结果还是更新前的值。

三、原生事件中的setState

class App extends Component {

state = { val: 0 }

changeValue = () => {

this.setState({ val: this.state.val + 1 })

console.log(this.state.val) // 输出的是更新后的值 --> 1

}

componentDidMount() {

document.body.addEventListener(‘click’, this.changeValue, false)

}

render() {

return (

{Counter is: ${this.state.val}}

)

}

原生事件是指非react合成事件，原生自带的事件监听 addEventListener ，或者也可以用原生js、jq直接 document.querySelector().onclick 这种绑定事件的形式都属于原生事件。

原生事件的调用栈就比较简单了，因为没有走合成事件的那一大堆，直接触发click事件，到 requestWork ,在requestWork里由于 expirationTime === Sync 的原因，直接走了 performSyncWork 去更新，并不像合成事件或钩子函数中被return，所以当你在原生事件中setState后，能同步拿到更新后的state值。

四、setTimeout中的setState

class App extends Component {

state = { val: 0 }

componentDidMount() {

setTimeout(_ => {

this.setState({ val: this.state.val + 1 })

console.log(this.state.val) // 输出更新后的值 --> 1

}, 0)

}

render() {

return (

{Counter is: ${this.state.val}}

)

}

在 setTimeout 中去 setState 并不算是一个单独的场景，它是随着你外层去决定的，因为你可以在合成事件中 setTimeout ，可以在钩子函数中 setTimeout ，也可以在原生事件setTimeout，但是不管是哪个场景下，基于event loop的模型下， setTimeout 中里去 setState 总能拿到最新的state值。

举个栗子，比如之前的合成事件，由于你是 setTimeout(_ => { this.setState()}, 0) 是在 try 代码块中,当你 try 代码块执行到 setTimeout 的时候，把它丢到列队里，并没有去执行，而是先执行的 finally 代码块，等 finally 执行完了， isBatchingUpdates 又变为了 false ，导致最后去执行队列里的 setState 时候， requestWork 走的是和原生事件一样的 expirationTime === Sync if分支，所以表现就会和原生事件一样，可以同步拿到最新的state值。

五、setState中的批量更新

class App extends Component {

state = { val: 0 }

batchUpdates = () => {

this.setState({ val: this.state.val + 1 })

}

render() {

return (

{Counter is ${this.state.val}} // 1

)

}

上面的结果最终是1，在 setState 的时候react内部会创建一个 updateQueue ，通过 firstUpdate 、 lastUpdate 、 lastUpdate.next 去维护一个更新的队列，在最终的 performWork 中，相同的key会被覆盖，只会对最后一次的 setState 进行更新，下面是部分实现代码：