建站
咨詢
售后
建站咨詢
新聞中心
大家好，我卡頌。
創(chuàng)新互聯(lián)建站主要從事成都網(wǎng)站設(shè)計、成都網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)大柴旦,10年網(wǎng)站建設(shè)經(jīng)驗,價格優(yōu)惠、服務(wù)專業(yè),歡迎來電咨詢建站服務(wù):18982081108
有一句話相信大家都聽過：
取代泡面的，并不是更高級的泡面，而是外賣的興起。
在前端領(lǐng)域，也存在同樣的現(xiàn)象。作為前端緩存庫中的佼佼者，React-Query一直擁有大量受眾，官方推出的React-Query課程都賣出了8w+份。
但就是這樣一款能打的產(chǎn)品，居然有被淘汰的風(fēng)險，這究竟是為什么？
本文參考了文章You Might Not Need React Query[1]
前端緩存庫的本質(zhì)
React-Query的定位是「前端緩存庫」。如果從前端的視角來理解這個庫，可能會認(rèn)為它是axios加強(qiáng)版。
但要理解這個庫的本質(zhì)，其實需要我們從后端的視角出發(fā)。
在后端看來，后端負(fù)責(zé)提供數(shù)據(jù)，前端負(fù)責(zé)展示數(shù)據(jù)，那么：
- 數(shù)據(jù)更新后，前端應(yīng)該如何渲染？
- 數(shù)據(jù)失效后，前端應(yīng)該如何渲染？
本質(zhì)來說，這是個「數(shù)據(jù)/緩存同步」的問題，只不過在SPA時代，這個問題剛好交給前端解決而已。
但是，后端天生離數(shù)據(jù)更近，解決這個問題更有優(yōu)勢。所以當(dāng)渲染任務(wù)逐漸移向后端，React-Query（或類似的庫）便逐漸失去市場。
總結(jié)來說：取代React-Query的，并不是更先進(jìn)的競品，而是他存在的土壤正在逐漸消失。
SSR技術(shù)的更迭
這里說的「渲染任務(wù)逐漸移向后端」就是指SSR（服務(wù)端渲染）。但是，SSR出現(xiàn)很多年了，為什么之前沒有說要取代React-Query？
這是因為，傳統(tǒng)的SSR主要應(yīng)用在數(shù)據(jù)的首屏渲染。當(dāng)首屏渲染完成，數(shù)據(jù)的后續(xù)同步操作還是發(fā)生在前端。
所以，React-Query還是有用武之地。
類似的，在全?？蚣躈ext.js中，也推薦在CSR（客戶端渲染）時使用同團(tuán)隊開發(fā)的緩存庫SWR用于數(shù)據(jù)的同步操作。
但是，隨著SSR框架開始支持「序列化數(shù)據(jù)」，這一切都變了。
序列化數(shù)據(jù)的意義
在React中，對于如下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個特點：
- 是序列化數(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é)果進(jìn)行細(xì)粒度的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 (
);
}當(dāng)點擊按鈕，觸發(fā)后端執(zhí)行addItem方法，方法的返回值會以RSC的序列化數(shù)據(jù)的形式返回給前端。
總結(jié)
除了RSC的序列化數(shù)據(jù)，Qwik是另一款應(yīng)用序列化數(shù)據(jù)的SSR框架。
這些框架的理念都是 —— 后端優(yōu)先。即：業(yè)務(wù)邏輯如果能放在后端，那就放在后端。
沒曾想，隨著這些全?？蚣艿谋l(fā)，前端緩存庫React-Query成為受傷最重的那個。
這就是所謂的 —— 毀滅你，與你何干。
參考資料
[1]You Might Not Need React Query:https://tkdodo.eu/blog/you-might-not-need-react-query。
分享名稱：React-Query：啥都沒干，就被淘汰了？
本文來源：http://m.5511xx.com/article/cdhjdoe.html
