日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

RELATEED CONSULTING
相關咨詢
選擇下列產(chǎn)品馬上在線溝通
服務時間：8:30-17:00
你可能遇到了下面的問題
關閉右側工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案
React中setState是一個宏任務還是微任務？

最近有個朋友面試，面試官問了個奇葩的問題，也就是我寫在標題上的這個問題。

創(chuàng)新互聯(lián)成立10年來，這條路我們正越走越好，積累了技術與客戶資源，形成了良好的口碑。為客戶提供網(wǎng)站設計、成都網(wǎng)站制作、網(wǎng)站策劃、網(wǎng)頁設計、域名與空間、網(wǎng)絡營銷、VI設計、網(wǎng)站改版、漏洞修補等服務。網(wǎng)站是否美觀、功能強大、用戶體驗好、性價比高、打開快等等，這些對于網(wǎng)站建設都非常重要，創(chuàng)新互聯(lián)通過對建站技術性的掌握、對創(chuàng)意設計的研究為客戶提供一站式互聯(lián)網(wǎng)解決方案，攜手廣大客戶，共同發(fā)展進步。

能問出這個問題，面試官應該對 React 不是很了解，也是可能是看到面試者簡歷里面有寫過自己熟悉 React，面試官想通過這個問題來判斷面試者是不是真的熟悉 React ??。

面試官的問法是否正確?

面試官的問題是，setState 是一個宏認為還是微任務，那么在他的認知里，setState 肯定是一個異步操作。為了判斷 setState 到底是不是異步操作，可以先做一個實驗，通過 CRA 新建一個 React 項目，在項目中，編輯如下代碼：

 
 
 
 
    
  
  
  
  
  1. import React from 'react'; 
    2. 
  
  
  
  
  2. import logo from './logo.svg'; 
    3. 
  
  
  
  
  3. import './App.css'; 
    4. 
  
  
  
  
  4.  
    5. 
  
  
  
  
  5. class App extends React.Component { 
    6. 
  
  
  
  
  6.   state = { 
    7. 
  
  
  
  
  7.     count: 1000 
    8. 
  
  
  
  
  8.   } 
    9. 
  
  
  
  
  9.   render() { 
    10. 
  
  
  
  
  10.     return ( 
    11. 
  
  
  
  
  11.        
    12. 
  
  
  
  
  12.         
  
  
  
  
  13.           src={logo} alt="logo" 
    14. 
  
  
  
  
  14.           className="App-logo" 
    15. 
  
  
  
  
  15.           onClick={this.handleClick} 
    16. 
  
  
  
  
  16.         /> 
    17. 
  
  
  
  
  17.         
    我的關注人數(shù)：{this.state.count}
     
    18. 
  
  
  
  
  18.       
 
  •     ); 
  •   } 
  • } 
  •  
  • export default App; 

    • 頁面大概長這樣：

    上面的 React Logo 綁定了一個點擊事件，現(xiàn)在需要實現(xiàn)這個點擊事件，在點擊 Logo 之后，進行一次 setState 操作，在 set 操作完成時打印一個 log，并且在 set 操作之前，分別添加一個宏任務和微任務。代碼如下：

     
 
 
 
      
  
  
  
  
    1. handleClick = () => { 
      2. 
  
  
  
  
    2.   const fans = Math.floor(Math.random() * 10) 
      3. 
  
  
  
  
    3.   setTimeout(() => { 
      4. 
  
  
  
  
    4.     console.log('宏任務觸發(fā)') 
      5. 
  
  
  
  
    5.   }) 
      6. 
  
  
  
  
    6.   Promise.resolve().then(() => { 
      7. 
  
  
  
  
    7.     console.log('微任務觸發(fā)') 
      8. 
  
  
  
  
    8.   }) 
      9. 
  
  
  
  
    9.   this.setState({ 
      10. 
  
  
  
  
    10.     count: this.state.count + fans 
      11. 
  
  
  
  
    11.   }, () => { 
      12. 
  
  
  
  
    12.     console.log('新增粉絲數(shù):', fans) 
      13. 
  
  
  
  
    13.   }) 
      14. 
  
  
  
  
    14. } 
      15.

    很明顯，在點擊 Logo 之后，先完成了 setState 操作，然后再是微任務的觸發(fā)和宏任務的觸發(fā)。所以，setState 的執(zhí)行時機是早于微任務與宏任務的，即使這樣也只能說它的執(zhí)行時機早于 Promise.then，還不能證明它就是同步任務。

     
 
 
 
      
  
  
  
  
    1. handleClick = () => { 
      2. 
  
  
  
  
    2.   const fans = Math.floor(Math.random() * 10) 
      3. 
  
  
  
  
    3.   console.log('開始運行') 
      4. 
  
  
  
  
    4.   this.setState({ 
      5. 
  
  
  
  
    5.     count: this.state.count + fans 
      6. 
  
  
  
  
    6.   }, () => { 
      7. 
  
  
  
  
    7.     console.log('新增粉絲數(shù):', fans) 
      8. 
  
  
  
  
    8.   }) 
      9. 
  
  
  
  
    9.   console.log('結束運行') 
      10. 
  
  
  
  
    10. } 
      11.

    這么看，似乎 setState 又是一個異步的操作。主要原因是，在 React 的生命周期以及綁定的事件流中，所有的 setState 操作會先緩存到一個隊列中，在整個事件結束后或者 mount 流程結束后，才會取出之前緩存的 setState 隊列進行一次計算，觸發(fā) state 更新。只要我們跳出 React 的事件流或者生命周期，就能打破 React 對 setState 的掌控。最簡單的方法，就是把 setState 放到 setTimeout 的匿名函數(shù)中。

     
 
 
 
      
  
  
  
  
    1. handleClick = () => { 
      2. 
  
  
  
  
    2.   setTimeout(() => { 
      3. 
  
  
  
  
    3.     const fans = Math.floor(Math.random() * 10) 
      4. 
  
  
  
  
    4.     console.log('開始運行') 
      5. 
  
  
  
  
    5.     this.setState({ 
      6. 
  
  
  
  
    6.       count: this.state.count + fans 
      7. 
  
  
  
  
    7.     }, () => { 
      8. 
  
  
  
  
    8.       console.log('新增粉絲數(shù):', fans) 
      9. 
  
  
  
  
    9.     }) 
      10. 
  
  
  
  
    10.     console.log('結束運行') 
      11. 
  
  
  
  
    11.   }) 
      12. 
  
  
  
  
    12. } 
      13.

    所以，setState 就是一次同步行為，根本不存在面試官的問題。

    React 是如何控制 setState 的 ?

    前面的案例中，setState 只有在 setTimeout 中才會變得像一個同步方法，這是怎么做到的?

     
 
 
 
      
  
  
  
  
    1. handleClick = () => { 
      2. 
  
  
  
  
    2.   // 正常的操作 
      3. 
  
  
  
  
    3.   this.setState({ 
      4. 
  
  
  
  
    4.     count: this.state.count + 1 
      5. 
  
  
  
  
    5.   }) 
      6. 
  
  
  
  
    6. } 
      7. 
  
  
  
  
    7. handleClick = () => { 
      8. 
  
  
  
  
    8.   // 脫離 React 控制的操作 
      9. 
  
  
  
  
    9.   setTimeout(() => { 
      10. 
  
  
  
  
    10.     this.setState({ 
      11. 
  
  
  
  
    11.       count: this.state.count + fans 
      12. 
  
  
  
  
    12.     }) 
      13. 
  
  
  
  
    13.   }) 
      14. 
  
  
  
  
    14. } 
      15.

    先回顧之前的代碼，在這兩個操作中，我們分別在 Performance 中記錄一次調用棧，看看兩者的調用棧有何區(qū)別。

    正常操作

    脫離 React 控制的操作

    在調用棧中，可以看到 Component.setState 方法最終會調用 enqueueSetState 方法，而 enqueueSetState 方法內(nèi)部會調用 scheduleUpdateOnFiber 方法，區(qū)別就在于正常調用的時候，scheduleUpdateOnFiber 方法內(nèi)只會調用 ensureRootIsScheduled ，在事件方法結束后，才會調用 flushSyncCallbackQueue 方法。而脫離 React 事件流的時候，scheduleUpdateOnFiber 在 ensureRootIsScheduled 調用結束后，會直接調用 flushSyncCallbackQueue 方法，這個方法就是用來更新 state 并重新進行 render 。

     
 
 
 
      
  
  
  
  
    1. function scheduleUpdateOnFiber(fiber, lane, eventTime) { 
      2. 
  
  
  
  
    2.   if (lane === SyncLane) { 
      3. 
  
  
  
  
    3.     // 同步操作 
      4. 
  
  
  
  
    4.     ensureRootIsScheduled(root, eventTime); 
      5. 
  
  
  
  
    5.     // 判斷當前是否還在 React 事件流中 
      6. 
  
  
  
  
    6.     // 如果不在，直接調用 flushSyncCallbackQueue 更新 
      7. 
  
  
  
  
    7.     if (executionContext === NoContext) { 
      8. 
  
  
  
  
    8.       flushSyncCallbackQueue(); 
      9. 
  
  
  
  
    9.     } 
      10. 
  
  
  
  
    10.   } else { 
      11. 
  
  
  
  
    11.     // 異步操作 
      12. 
  
  
  
  
    12.   } 
      13. 
  
  
  
  
    13. } 
      14.

    上述代碼可以簡單描述這個過程，主要是判斷了 executionContext 是否等于 NoContext 來確定當前更新流程是否在 React 事件流中。

    眾所周知，React 在綁定事件時，會對事件進行合成，統(tǒng)一綁定到 document 上( react@17 有所改變，變成了綁定事件到 render 時指定的那個 DOM 元素)，最后由 React 來派發(fā)。

    所有的事件在觸發(fā)的時候，都會先調用 batchedEventUpdates$1 這個方法，在這里就會修改 executionContext 的值，React 就知道此時的 setState 在自己的掌控中。

     
 
 
 
      
  
  
  
  
    1. // executionContext 的默認狀態(tài) 
      2. 
  
  
  
  
    2. var executionContext = NoContext; 
      3. 
  
  
  
  
    3. function batchedEventUpdates$1(fn, a) { 
      4. 
  
  
  
  
    4.   var prevExecutionContext = executionContext; 
      5. 
  
  
  
  
    5.   executionContext |= EventContext; // 修改狀態(tài) 
      6. 
  
  
  
  
    6.   try { 
      7. 
  
  
  
  
    7.     return fn(a); 
      8. 
  
  
  
  
    8.   } finally { 
      9. 
  
  
  
  
    9.     executionContext = prevExecutionContext; 
      10. 
  
  
  
  
    10.   // 調用結束后，調用 flushSyncCallbackQueue 
      11. 
  
  
  
  
    11.     if (executionContext === NoContext) { 
      12. 
  
  
  
  
    12.       flushSyncCallbackQueue(); 
      13. 
  
  
  
  
    13.     } 
      14. 
  
  
  
  
    14.   } 
      15. 
  
  
  
  
    15. } 
      16.

    所以，不管是直接調用 flushSyncCallbackQueue ，還是推遲調用，這里本質上都是同步的，只是有個先后順序的問題。

    未來會有異步的 setState

    如果你有認真看上面的代碼，你會發(fā)現(xiàn)在 scheduleUpdateOnFiber 方法內(nèi)，會判斷 lane 是否為同步，那么是不是存在異步的情況?

     
 
 
 
      
  
  
  
  
    1. function scheduleUpdateOnFiber(fiber, lane, eventTime) { 
      2. 
  
  
  
  
    2.   if (lane === SyncLane) { 
      3. 
  
  
  
  
    3.     // 同步操作 
      4. 
  
  
  
  
    4.     ensureRootIsScheduled(root, eventTime); 
      5. 
  
  
  
  
    5.     // 判斷當前是否還在 React 事件流中 
      6. 
  
  
  
  
    6.     // 如果不在，直接調用 flushSyncCallbackQueue 更新 
      7. 
  
  
  
  
    7.     if (executionContext === NoContext) { 
      8. 
  
  
  
  
    8.       flushSyncCallbackQueue(); 
      9. 
  
  
  
  
    9.     } 
      10. 
  
  
  
  
    10.   } else { 
      11. 
  
  
  
  
    11.     // 異步操作 
      12. 
  
  
  
  
    12.   } 
      13. 
  
  
  
  
    13. } 
      14.

    React 在兩年前，升級 fiber 架構的時候，就是為其異步化做準備的。在 React 18 將會正式發(fā)布 Concurrent 模式，關于 Concurrent 模式，官方的介紹如下。

    什么是 Concurrent 模式?

    Concurrent 模式是一組 React 的新功能，可幫助應用保持響應，并根據(jù)用戶的設備性能和網(wǎng)速進行適當?shù)恼{整。在 Concurrent 模式中，渲染不是阻塞的。它是可中斷的。這改善了用戶體驗。它同時解鎖了以前不可能的新功能。

    現(xiàn)在如果想使用 Concurrent 模式，需要使用 React 的實驗版本。

    本文轉載自微信公眾號「自然醒的筆記本」，可以通過以下二維碼關注。轉載本文請聯(lián)系自然醒的筆記本公眾號。


    網(wǎng)頁名稱：React中setState是一個宏任務還是微任務？
    分享路徑：http://www.5511xx.com/article/ccsidds.html