React-Query: you were eliminated after doing nothing?

May 26, 2023 1419hotness 0likes 0comments

there is a sentence that I believe everyone has heard:

the replacement of instant noodles is not the more advanced instant noodles, but the rise of takeout

the same phenomenon exists in the front-end domain. As a leader in the front-end cache, React-Query has always had a large audience, and the official React-Query courses have sold 8w + copies.

but it is such a hit product that there is a risk of being eliminated. Why on earth?

Nature of the front-end cache

React-Query is located as front-end cache . If you understand the library from a front-end perspective, you might think of it as an enhanced version of axios .

but to understand the nature of this library, we need to start from a back-end perspective.

in the view of the back end, the back end is responsible for providing the data, and the front end is responsible for displaying the data, so:

how should the front end render after the data is updated?
After data invalidation, how should the front end render?

In essence, this is a data / cache synchronization problem, but in the SPA era, this problem happens to be left to the front end.

however, the back end is inherently closer to the data, and it has an advantage to solve this problem. So as rendering tasks gradually move to the back end, React-Query (or similar libraries) gradually lose market.

To sum up: what replaces React-Query is not a more advanced competition, but that the soil in which it exists is gradually disappearing.

change of SSR technology

the rendering task here is gradually moving to the backend , which means SSR (server rendering). However, SSR has been around for many years, so why didn't you mention replacing React-Query before?

this is because the traditional SSR is mainly used in the first screen rendering of data. When the rendering of the first screen is completed, the subsequent synchronization of the data still occurs at the front end.

so, React-Query still has the opportunity to use his talents.

Similarly, in the full-stack framework Next.js , it is also recommended to use the cache SWR developed by the same team for data synchronization when CSR (client rendering).

however, all this has changed as the SSR framework begins to support serializing data .

significance of serializing data

in React , for the following JSX :

const name = "Kasong";
<p>Hello, {name}</p>

in the traditional SSR , after being processed by the back end, the structure passed to the front end is the following HTML structure:

<p>Hello, Carson.</p>

The HTML structure can be rendered directly, which is convenient, but it also loses flexibility (hard to update).

so the traditional SSR is mainly used in one-off processes such as first screen rendering .

in React Server Component , after the same JSX structure is serialized through the back end, the data structure passed to the front end is the following data structure Content-Type which is text/x-component :

0:["$@1",null]
1:["$","p",null,{"children":["Hello, Carson."]}]

this data structure has two characteristics:

is serialized data. React can recognize after deserialization.
one data per row to facilitate streaming

serializing data can significantly increase the flexibility of SSR .

says this because the previous SSR can only return HTML structure, so SSR is mainly used for HTML first screen rendering from 0 to 1.

now, SSR supports serializing data. The front-end framework can recognize the result of SSR , and can manipulate this result to make fine-grained HTML updates.

apply this model to data synchronization scenario:

Before, the logic of data synchronization mainly occurred in React-Query located at the front end .
now, the logic of data synchronization occurs in the backend

since the logic of data synchronization occurs at the back end, there is obviously no need for React-Query running on the front end.

moreover, the serialize data scheme has the benefit of putting logic on the back end of any module that can be serialized.

although React Server Component is literally translated as a server-side component, it seems that the smallest serializable module should be a component.

however, the scope of the function can also be used as a serialization module as long as the specification is followed.

for example, in the following Next.js code, the AddToCart component renders at the front end, and the logic of the addItem method is the back-end logic of operating the database:

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">add to cart</button>
    </form>
  );
}

when the button is clicked, the backend is triggered to execute the addItem method, and the returned value of the method is returned to the front end in the form of serialized data of RSC .