大家好，我卡頌。

有一句話相信大家都聽過：

取代泡面的，并不是更高級的泡面，而是外賣的興起。

在前端領(lǐng)域，也存在同樣的現(xiàn)象。作為前端緩存庫中的佼佼者，React-Query一直擁有大量受眾，官方推出的React-Query課程都賣出了8w+份。

但就是這樣一款能打的產(chǎn)品，居然有被淘汰的風險，這究竟是為什么？

本文參考了文章You Might Not Need React Query[1]

前端緩存庫的本質(zhì)

React-Query的定位是「前端緩存庫」。如果從前端的視角來理解這個庫，可能會認為它是axios加強版。

但要理解這個庫的本質(zhì)，其實需要我們從后端的視角出發(fā)。

在后端看來，后端負責提供數(shù)據(jù)，前端負責展示數(shù)據(jù)，那么：

• 數(shù)據(jù)更新后，前端應(yīng)該如何渲染？
• 數(shù)據(jù)失效后，前端應(yīng)該如何渲染？

本質(zhì)來說，這是個「數(shù)據(jù)/緩存同步」的問題，只不過在SPA時代，這個問題剛好交給前端解決而已。

但是，后端天生離數(shù)據(jù)更近，解決這個問題更有優(yōu)勢。所以當渲染任務(wù)逐漸移向后端，React-Query（或類似的庫）便逐漸失去市場。

總結(jié)來說：取代React-Query的，并不是更先進的競品，而是他存在的土壤正在逐漸消失。

SSR技術(shù)的更迭

這里說的「渲染任務(wù)逐漸移向后端」就是指SSR（服務(wù)端渲染）。但是，SSR出現(xiàn)很多年了，為什么之前沒有說要取代React-Query？

這是因為，傳統(tǒng)的SSR主要應(yīng)用在數(shù)據(jù)的首屏渲染。當首屏渲染完成，數(shù)據(jù)的后續(xù)同步操作還是發(fā)生在前端。

所以，React-Query還是有用武之地。

類似的，在全?？蚣躈ext.js中，也推薦在CSR（客戶端渲染）時使用同團隊開發(fā)的緩存庫SWR用于數(shù)據(jù)的同步操作。

但是，隨著SSR框架開始支持「序列化數(shù)據(jù)」，這一切都變了。

序列化數(shù)據(jù)的意義

在React中，對于如下JSX：

const name = "卡頌";
<p>你好，{name}</p>

在傳統(tǒng)SSR中，經(jīng)由后端處理后，傳遞給前端的是如下HTML結(jié)構(gòu)：

<p>你好，卡頌</p>

HTML結(jié)構(gòu)可以直接渲染，很方便，但也失去了靈活性（不好更新）。

所以傳統(tǒng)SSR主要應(yīng)用在「首屏渲染」這樣的一次性過程。

在React Server Component中，同樣的JSX結(jié)構(gòu)經(jīng)由后端序列化后，傳遞給前端的是Content-Type為text/x-component的如下數(shù)據(jù)結(jié)構(gòu)：

0:["$@1",null]
1:["$","p",null,{"children":["你好，卡頌"]}]

這種數(shù)據(jù)結(jié)構(gòu)有2個特點：

• 是序列化數(shù)據(jù)，反序列化后React可以識別。
• 每行一條數(shù)據(jù)，方便流式傳輸。

序列化數(shù)據(jù)可以顯著提高SSR的靈活性。

之所以這么說是因為，之前的SSR只能返回HTML結(jié)構(gòu)，所以SSR主要用于HTML從0到1的首屏渲染。

現(xiàn)在，SSR支持序列化數(shù)據(jù)。前端框架能夠識別SSR的結(jié)果，就能操作這個結(jié)果進行細粒度的HTML更新。

把這個模型套在「數(shù)據(jù)同步」的場景：

• 之前，「數(shù)據(jù)同步」的邏輯主要發(fā)生在位于前端的React-Query中。
• 現(xiàn)在，「數(shù)據(jù)同步」的邏輯發(fā)生在后端。

既然「數(shù)據(jù)同步」的邏輯發(fā)生在后端，顯然就不需要運行在前端的React-Query了。

而且，「序列化數(shù)據(jù)」方案還有個好處 —— 凡是能夠序列化的模塊，都能將邏輯放在后端執(zhí)行。

雖然React Server Component直譯叫服務(wù)端組件，看起來「最小可序列化」的模塊應(yīng)該是組件。

但是，只要遵循規(guī)范，其實「函數(shù)作用域」也能作為序列化的模塊。

比如，在如下Next.js代碼中，AddToCart組件在前端渲染，addItem方法的邏輯是操作數(shù)據(jù)庫的后端邏輯：

import { cookies } from 'next/headers';
 
export default function AddToCart() {
  async function addItem(data) {
    'use server';
    const cartId = cookies().get('cartId')?.value;
    const id = await saveToDb({ cartId, data });
    return id;
  }
 
  return (
    <form action={addItem}>
      <button type="submit">加入購物車</button>
    </form>
  );
}

當點擊按鈕，觸發(fā)后端執(zhí)行addItem方法，方法的返回值會以RSC的序列化數(shù)據(jù)的形式返回給前端。

總結(jié)

除了RSC的序列化數(shù)據(jù)，Qwik是另一款應(yīng)用序列化數(shù)據(jù)的SSR框架。

這些框架的理念都是 —— 后端優(yōu)先。即：業(yè)務(wù)邏輯如果能放在后端，那就放在后端。

沒曾想，隨著這些全棧框架的爆發(fā)，前端緩存庫React-Query成為受傷最重的那個。

這就是所謂的 —— 毀滅你，與你何干。

參考資料

[1]You Might Not Need React Query:https://tkdodo.eu/blog/you-might-not-need-react-query。