先預警一下，完全消化本文內容有點難。

• useDeferredValue 解決真實場景問題的案例。
• useDeferredValue 基礎知識。
• 復雜案例渲染過程分析。
• useDeferredValue 底層執行原理分析。
• 重新分析取消請求案例。

全文共 5104 字，閱讀需要花費 10 分鐘。

useDeferredValue，一個出了很久，但是我幾乎沒咋在實踐中用到過的超冷門 hook。它有多冷門呢，我之前甚至都覺得沒必要介紹它。

直到前幾天，一個粉絲給了我重要的思路，我才認識到它的威力，逐漸深入了解之后發現它簡直就是一個寶藏 hook，說它是為了 Suspense 量身訂做的都不為過。

原來我一直都小瞧了它....

它的存在，直接補齊了 React 19 新架構思維最佳實踐的最后一塊短板。

正因為認識到了它的重要性，所以我迫不及待的想把它分享給大家。

一、遇到了一個問題

如圖所示，在之前的案例中，我想要實現這樣一個功能：當我快速在輸入框中輸入內容時，我希望請求能自動發生，并且請求發生時，之前存在的列表不能被替換為 Loading 組件。

此時，我使用 useTransition 勉強實現了該功能。主要代碼如下：

export default function Index() {
  const [api, setApi] = useState(postApi)
  const [isPending, startTransition] = useTransition()

  function __inputChange() {
    startTransition(() => {
      api.cancel()
      setApi(postApi())
    })
  }
  ....

<Suspense fallback={<div>loading...</div>}>
  <List api={api} isPending={isPending} />
</Suspense>

const List = ({api, isPending}) => {
  const posts = use(api)
  
  return (
    <ul className='_04_list' style={{opacity: isPending ? 0.5 : 1}}>
      {posts.map((post) => (
        <div key={post.id} className='_04_item'>
          <h2>{post.title}</h2>
          <p>{post.body}</p>
        </div>
      ))}
    </ul>
  )
}

useTransition 能夠阻止 Suspense 在請求發生時，渲染 fallback 中的 Loading 組件，并且，isPending 也能表示請求正在發生，因此，我把 isPending 傳入到子組件中，那么我們就可以在子組件中自定義請求狀態。

這基本達到了我想要的交互效果。

但是一個嚴重的問題是，我每次輸入，都會發送一個請求，當我快速輸入時，我希望通過取消上一次還沒完成的請求的方式來優化交互效果。useTransition 并不支持我這樣做。

核心原因是因為 useTransition 的任務會排隊依次執行，當我想要在下一個任務開始時，取消上一個請求時，上一個任務已經執行完了。因此 api.cancel() 雖然成功執行了，但是并起不到取消請求的效果，它執行時，已經沒有未完成的請求了。

useTransition 無法取消請求。我思考了很久，也沒摸索出來一個合適的方案。因此之前我只能使用防抖來做這個優化。

const [api, setApi] = useState(postApi)
const [isPending, startTransition] = useTransition()
const timer = useRef(null)

function __inputChange() {
  clearTimeout(timer.current)
  timer.current = setTimeout(() => {
    startTransition(() => {
      api.cancel()
      setApi(postApi())
    })
  }, 300)  
}
...

但是很顯然，這不是很優雅，因為防抖實際上和 useTransition 有類似的作用，用了防抖之后，useTransition 在這里的存在就變得有點尷尬了。

意外之喜的是，有大佬級別的粉絲在評論區給我提供了一個非常優雅的解決思路。那就是利用 useDeferredValue。

按照粉絲的思路，我把代碼改造如下：

export default function Index() {
  const [api, setApi] = useState(postApi)
  const deferred = useDeferredValue(api)

  function __inputChange(e) {
    api.cancel()
    setApi(postApi())
  }
  ...

<Suspense fallback={<div>loading...</div>}>
  <List api={deferred} isPending={api !== deferred} />
</Suspense>

驗證之后發現，我靠，成了！

肅然起敬?。。?！

在保證了代碼優雅的情況之下，輕松實現了我理想中的效果。useDeferredValue 直接補齊了 React 19 異步開發中，最佳實踐的最后一塊短板!

代碼就這么幾行，但是要理解 useDeferredValue，可能就要花點時間了。我們一起來學習一下。

二、useDeferredValue 基礎

useDeferredValue 是一個可以推遲 UI 更新的 hook。這句話理解起來有點困難。需要我稍微給各位道友解讀一下。

在正常情況下，一個 state 的變化，會導致 UI 發生變化。例如下面這個案例。

function Index() {
  const [counter, setCounter] = useState(0)

  function __clickHanler() {
    setCounter(counter + 1)
  }

  return (
    <div>
      <div id='tips'>基礎案例，state 遞增</div>
      <button onClick={__clickHanler}>counter++</button>
      <div className="counter">counter: {counter}</div>
      <div className="counter">counter: {counter}</div>
    </div>
  )
}

這里需要注意的是，狀態 counter 被兩個元素使用，因此，這兩個元素的更改，實際上是一個任務。他們必定會同時響應 counter 的變化。

但是這個時候，我們可以利用 useDeferredValue，把他們拆分成兩個任務。

function Index() {
  const [counter, setCounter] = useState(0)
  const deferred = useDeferredValue(counter)

  function __clickHanler() {
    setCounter(counter + 1)
  }

  return (
    <div>
      <div id='tips'>基礎案例，state 遞增</div>
      <button onClick={__clickHanler}>counter++</button>
      <div className="counter">
        counter: {counter}
      </div>
      <div className="counter">
        counter: {deferred}
      </div>
    </div>
  )
}

注意看，我們使用 counter 作為 useDeferredValue 的初始值，并將其返回值替換第二個元素。

const deferred = useDeferredValue(counter)

<div className="counter">
  counter: {deferred}
</div>

此時，第二個元素的更新，就不再與第一個元素同步。它更新的優先級被降低。這個時候它的執行在理論上是可以被更高的優先級插隊和中斷的。

但是由于渲染都太短了，我們肉眼無法區分出來兩個任務已經被分開了，因此我們把第二個元素重構成一個子組件，并模擬成一個耗時組件。此時我們就能明顯看出區別來。

<Expensive counter={deferred} />

const Expensive = ({counter}) => {
  const start = performance.now()
  while (performance.now() - start < 200) {}
  return (
    <div className="counter">Deferred: {counter}</div>
  )
}

演示效果如下。

因此，我們可以利用 useDeferredValue 推遲 UI 的更新。將對應任務的優先級降低，使其可以被插隊與中斷。

三、復雜案例分析

在這里，我們要更加清楚的理解任務和渲染任務，才能對案例的分析更加的精準。以上一個例子的 Expensive 組件為例。

狀態變化時，diff 會發生，Expensive 函數本身作為 diff 過程的一部分，它必定也會執行，但是這里我們注意，它對應的渲染任務，卻是可以被阻止執行的。

例如在上面的例子中，當我快速點擊按鈕遞增時，Expensive 組件不會依次遞增。效果如下：

我們發現，Expensive 組件的渲染直接從 0 變成了 7。

這是因為作為一個耗時任務，又被標記了低優先級，因此它的渲染任務不停的被優先級更高的 counter 中斷并放棄。因此直接從 0 變成了 7。

但是此時我們也發現另外一個情況，那就是 counter 直接對應的高優先級執行也沒有那么流暢，這是為什么呢？其實很簡單，因為在我們的模擬案例中，并沒有把耗時定位在渲染上。這可能和實踐情況會不太一樣。我們把耗時寫在了 Expensive 函數里，而這個函數每次都會執行，它的執行阻塞了渲染。

const Expensive = ({counter}) => {
  const start = performance.now()
  while (performance.now() - start < 200) {}
  return (
    <div className="counter">Deferred: {counter}</div>
  )
}

?

所以這里我們一定要區分開渲染任務和 Expensive 函數，他們是不同的，UI 渲染是一個異步任務，而 Expensive 函數是同步執行的。useDeferredValue 推遲的是 UI 渲染任務。因此，我們需要特別注意的是，不要在同步邏輯上執行過多的耗時任務。

但是我們可以通過任務拆分的方式，把執行耗時時間分散到更多的子組件中去，這樣 React 就可以利用任務中斷的機制，在不阻塞渲染的情況下，中斷低優先級的任務。

借用官網的一個復雜案例來跟大家演示。

function SlowList({ text }) {
  // Log once. The actual slowdown is inside SlowItem.
  console.log('[ARTIFICIALLY SLOW] Rendering 250 <SlowItem />');

  let items = [];
  for (let i = 0; i < 250; i++) {
    items.push(<SlowItem key={i} text={text} />);
  }
  return (
    <ul className="items">
      {items}
    </ul>
  );
}

function SlowItem({ text }) {
  let startTime = performance.now();
  while (performance.now() - startTime < 1) {
    // Do nothing for 1 ms per item to emulate extremely slow code
  }

  return (
    <li className="item">
      Text: {text}
    </li>
  )
}

此時我們注意觀察，不要錯漏這個細節。slowList 中包含了 250 個子組件。每個子組件都渲染 1ms，那么整個組件渲染就需要耗時至少 250ms。

在父組件中，我們把 deferred 傳遞給 SlowList。

<SlowList text={deferred} />

那么此時表示，slowList 的任務是低優先級。counter 對應的任務可以中斷它的執行。當我快速點擊時，執行效果如下。

此時一個很明顯的區別就是，counter 的 UI 變化變得更加流暢了。這是因為耗時被拆分到了多個子組件中，React 就有機會中斷這些函數的執行，并執行優先級更高的任務，以確保高優先級任務的流暢。

如果你沒有使用 React Compiler，你需要使用 memo 手動緩存 SlowList。

const SlowList = memo(function SlowList({ text }) {
  // ...
});

useDefferdValue 會首先使用舊值傳遞給組件。

<SlowList text={deferred} />

因此，當 counter 發生變化時，deferred 依然是舊值，那么此時，如果我們使用 memo 包裹，SlowList 的 props 就沒有發生變化，我們可以跳過此次針對 SlowList 的更新。

這跟 React 的性能優化策略有關。

四、運行原理

看了上面兩個例子，肯定還是有一部分人會覺得很懵，不要急，接下來我們把運行原理分析一下，整個情況就清晰了。

useDeferredValue 會嘗試將 UI 任務更新兩次。

第一次，會給子組件傳遞舊值。此時 SlowList 接收到的 props 會與上一次完全相同。如果結合了 React.memo，那么該組件就不會重新渲染。該組件可以重復使用之前的渲染結果。

?

Compiler 編譯之后不需要 memo。

此時，高優先級的任務渲染會發生，渲染完成之后，將會開始第二次渲染。此時，將會傳入剛才更新之后的新值。對于 SlowList 而言，props 發生了變化，整個組件會重新渲染。

我們通常會將已經非常明確的耗時任務標記為 deferred，因此，這些任務都被視為低優先級。當重要的高優先級更新已經完成，低優先級任務在第二次渲染時嘗試更新...

在它第二次更新的過程中，如果又有新的高優先級任務進來，那么 React 就會中斷并放棄第二次更新，去執行高優先級的任務。

i

注意：是中斷，并放棄這次更新，所以表現出來的結果就是，中間會漏掉許多任務的執行。

這樣的運行機制有一個非常重要的好處。

那就是，如果你的電腦性能足夠強悍，那么第二次的更新可能會快速完成，高優先級的任務來不及中斷，那么我們的頁面響應就是非常理想的。

但是如果我們的電腦性能比較差，第二次更新還沒完成，新的高優先級任務又來了，那么就可以通過中斷的方式，降級處理，保證重要 UI 的流暢，放棄低優先級任務。

?

在不同性能的設備上，有不同的反應，這個是跟防抖、節流的最重要的區別。

五、重新分析取消請求案例

那我們回過頭來，分析一下最開始的那個案例，重新看一眼代碼

export default function Index() {
  const [api, setApi] = useState(postApi)
  const deferred = useDeferredValue(api)

  function __inputChange(e) {
    api.cancel()
    setApi(postApi())
  }
  ...

<Suspense fallback={<div>loading...</div>}>
  <List api={deferred} isPending={api !== deferred} />
</Suspense>

這里我們將 api 做為 state，當 api 被重新賦值時，List 會經歷兩次更新。

首先點擊事件觸發，請求立即發生。api 被改變。觸發組件更新。

第一次更新時，deferred 使用舊值傳參，此時對于 List 而言，api 沒有發生變化。因此，利用這個機制，我們可以阻止 Suspense 直接渲染成 fallback。

在 Suspense 包裹之下，只有當接口請求成功之后，deferred 的第二次更新才會發生，因此，在這個過程中，如果我們快速進行第二次點擊，可以直接取消上一次請求，讓第二次更新來不及執行。此時新的請求發生。

?

這里要結合 Suspense 的執行機制來理解。

六、總結

這種場景的最佳實踐代碼非常的簡潔和優雅。寫起來也很舒服，性能也非常強悍。但是理解起來會比較困難。因此想要做到靈活運用，還需要多多消化。

但是，等你徹底掌握它之后，你就會發現 React 19 在異步交互上真的太優雅了。這樣的開發體驗，是依賴 useEffect 完全比不了的。

后續的分享中，我將會繼續為大家分享 React Action 的設計核心思維與具體使用。