旷世神医,大主宰之灵路天蚕土豆

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案

React-Query：啥都沒干，就被淘汰了？

大家好，我卡頌。

創(chuàng)新互聯(lián)建站主要從事成都網(wǎng)站設(shè)計(jì)、成都網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計(jì)、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)大柴旦,10年網(wǎng)站建設(shè)經(jīng)驗(yàn),價(jià)格優(yōu)惠、服務(wù)專業(yè),歡迎來電咨詢建站服務(wù):18982081108

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

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

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

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

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

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

React-Query的定位是「前端緩存庫」。如果從前端的視角來理解這個(gè)庫，可能會(huì)認(rèn)為它是axios加強(qiáng)版。

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

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

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

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

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

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

SSR技術(shù)的更迭

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

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

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

類似的，在全棧框架Next.js中，也推薦在CSR（客戶端渲染）時(shí)使用同團(tuán)隊(duì)開發(fā)的緩存庫SWR用于數(shù)據(jù)的同步操作。

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

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

在React中，對(duì)于如下JSX：

const name = "卡頌";
你好，{name}

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

你好，卡頌

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個(gè)特點(diǎn)：

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

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

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

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

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

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

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

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

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

但是，只要遵循規(guī)范，其實(shí)「函數(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 (
    
      
    
  );
}

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

總結(jié)

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

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

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

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

參考資料

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

當(dāng)前題目：React-Query：啥都沒干，就被淘汰了？
分享URL：http://fisionsoft.com.cn/article/cdhjdoe.html