大家好，我卡颂。
有一句话置信大家都听过：
取代泡面的，并不是更高级的泡面，而是外卖的衰亡
在前端畛域，也存在同样的景象。作为前端缓存库中的佼佼者，React-Query始终领有大量受众，官网推出的React-Query课程都卖出了8w+份。
但就是这样一款能打的产品，竟然有被淘汰的危险，这到底是为什么？
本文参考了文章You Might Not Need React Query
欢送退出人类高质量前端交换群，带飞
前端缓存库的实质
React-Query的定位是前端缓存库。如果从前端的视角来了解这个库，可能会认为它是axios加强版。
但要了解这个库的实质，其实须要咱们从后端的视角登程。
在后端看来，后端负责提供数据，前端负责展现数据，那么：
- 数据更新后，前端应该如何渲染？
- 数据生效后，前端应该如何渲染？
实质来说，这是个数据/缓存同步的问题，只不过在SPA时代，这个问题刚好交给前端解决而已。
然而，后端天生离数据更近，解决这个问题更有劣势。所以当渲染工作逐步移向后端，React-Query（或相似的库）便逐步失去市场。
总结来说：取代React-Query的，并不是更先进的竞品，而是他存在的土壤正在逐步隐没。
SSR技术的更迭
这里说的渲染工作逐步移向后端就是指SSR（服务端渲染）。然而，SSR呈现很多年了，为什么之前没有说要取代React-Query？
这是因为，传统的SSR次要利用在数据的首屏渲染。当首屏渲染实现，数据的后续同步操作还是产生在前端。
所以，React-Query还是有用武之地。
相似的，在全栈框架Next.js中，也举荐在CSR（客户端渲染）时应用同团队开发的缓存库SWR用于数据的同步操作。
然而，随着SSR框架开始反对序列化数据，这所有都变了。
序列化数据的意义
在React中，对于如下JSX：
const name = "卡颂";<p>你好，{name}</p>在传统SSR中，经由后端解决后，传递给前端的是如下HTML构造：
<p>你好，卡颂</p>HTML构造能够间接渲染，很不便，但也失去了灵活性（不好更新）。
所以传统SSR次要利用在首屏渲染这样的一次性过程。
在React Server Component中，同样的JSX构造经由后端序列化后，传递给前端的是Content-Type为text/x-component的如下数据结构：
0:["$@1",null]1:["$","p",null,{"children":["你好，卡颂"]}]这种数据结构有2个特点：
- 是序列化数据，反序列化后
React能够辨认 - 每行一条数据，不便流式传输
序列化数据能够显著进步SSR的灵活性。
之所以这么说是因为，之前的SSR只能返回HTML构造，所以SSR次要用于HTML从0到1的首屏渲染。
当初，SSR反对序列化数据。前端框架可能辨认SSR的后果，就能操作这个后果进行细粒度的HTML更新。
把这个模型套在数据同步的场景：
- 之前，数据同步的逻辑次要产生在位于前端的
React-Query中 - 当初，数据同步的逻辑产生在后端
既然数据同步的逻辑产生在后端，显然就不须要运行在前端的React-Query了。
而且，序列化数据计划还有个益处 —— 但凡可能序列化的模块，都能将逻辑放在后端执行。
尽管React Server Component直译叫服务端组件，看起来最小可序列化的模块应该是组件。
然而，只有遵循标准，其实函数作用域也能作为序列化的模块。
比方，在如下Next.js代码中，AddToCart组件在前端渲染，addItem办法的逻辑是操作数据库的后端逻辑：
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> );}当点击按钮，触发后端执行addItem办法，办法的返回值会以RSC的序列化数据的模式返回给前端。
总结
除了RSC的序列化数据，Qwik是另一款利用序列化数据的SSR框架。
这些框架的理念都是 —— 后端优先。即：业务逻辑如果能放在后端，那就放在后端。
没曾想，随着这些全栈框架的暴发，前端缓存库React-Query成为受伤最重的那个。
这就是所谓的 —— 覆灭你，与你何干。