RTK Query: el estado de servidor dentro de Redux

Al final de la lección de createAsyncThunk quedó una sospecha en el aire: si repites el trío pending, fulfilled, rejected para cada lectura de datos del servidor, estás construyendo a mano una cache. RTK Query es la conclusión de esa sospecha llevada hasta el final. En vez de escribir thunks y reducers para cada endpoint, declaras los endpoints una sola vez en createApi, y RTK genera por ti la cache completa: hooks de React que piden los datos, los guardan indexados, deduplican peticiones idénticas, marcan los estados de carga y error, y reejecutan la consulta cuando algo la invalida. El estado de servidor deja de vivir en slices escritos a mano y pasa a vivir en una cache que sabe caducar, deduplicar e invalidar por su cuenta, todo dentro del mismo store de Redux que ya tienes.

createApi: endpoints que generan hooks

Un createApi reúne toda la comunicación con un backend en un solo lugar. Le das un reducerPath donde vivirá su cache, un baseQuery que sabe hacer las peticiones —fetchBaseQuery cubre el caso común con una baseUrl y cabeceras— y un mapa de endpoints. Cada endpoint es una query de lectura o una mutation de escritura, y por cada uno RTK genera un hook con nombre derivado: listarPosts produce useListarPostsQuery, crearPost produce useCrearPostMutation. No escribes ni acciones ni reducers ni thunks; describes los endpoints y RTK fabrica la maquinaria.

import { createApi, fetchBaseQuery } from "@reduxjs/toolkit/query/react";

interface Post { id: string; titulo: string }
interface NuevoPost { titulo: string }

export const api = createApi({
  reducerPath: "api",
  baseQuery: fetchBaseQuery({ baseUrl: "/api" }),
  tagTypes: ["Post"],
  endpoints: (builder) => ({
    listarPosts: builder.query<Post[], void>({
      query: () => "posts",
      providesTags: ["Post"],
    }),
    crearPost: builder.mutation<Post, NuevoPost>({
      query: (cuerpo) => ({ url: "posts", method: "POST", body: cuerpo }),
      invalidatesTags: ["Post"],
    }),
  }),
});

export const { useListarPostsQuery, useCrearPostMutation } = api;

El único cableado en el store es registrar el reducer de la api y su middleware, y activar los listeners globales que refrescan al recuperar el foco o reconectar.

import { configureStore } from "@reduxjs/toolkit";
import { setupListeners } from "@reduxjs/toolkit/query";
import { api } from "./api";

export const store = configureStore({
  reducer: { [api.reducerPath]: api.reducer },
  middleware: (getDefaultMiddleware) =>
    getDefaultMiddleware().concat(api.middleware),
});

setupListeners(store.dispatch); // refetch al volver el foco o reconectar

Cache, deduplicación y ciclo de la query

El hook de una query devuelve un objeto con todo lo que la UI necesita: data cuando llega, error si falla, y las banderas isLoading, isFetching e isSuccess. La cache se indexa por el nombre del endpoint más los argumentos serializados, así que dos componentes que pidan listarPosts con los mismos argumentos comparten una sola entrada y una sola petición: RTK deduplica. Cuando nadie usa una entrada, un temporizador la conserva un tiempo —keepUnusedDataFor, sesenta segundos por defecto— y luego la descarta. La distinción entre isLoading e isFetching es fina pero importante: isLoading es cierto solo la primera vez, cuando no hay datos aún; isFetching es cierto en cualquier recarga, también cuando ya muestras datos viejos mientras llegan los nuevos.

function ListaPosts() {
  const { data, isLoading, isFetching, error } = useListarPostsQuery();
  const [crear, { isLoading: creando }] = useCrearPostMutation();

  if (isLoading) return <p>cargando por primera vez</p>;
  if (error) return <p>algo fallo</p>;

  return (
    <div>
      {isFetching && <span>actualizando en segundo plano</span>}
      <ul>{data?.map((p) => <li key={p.id}>{p.titulo}</li>)}</ul>
      <button disabled={creando} onClick={() => crear({ titulo: "nuevo" })}>
        crear
      </button>
    </div>
  );
}

Etiquetas: la invalidación automática

El sistema de etiquetas es lo que convierte a RTK Query de un fetcher en una cache coherente. Una query declara qué etiquetas provee con providesTags; una mutation declara qué etiquetas invalida con invalidatesTags. Cuando una mutation termina con éxito, RTK marca como obsoletas todas las queries que proveían las etiquetas invalidadas y las reejecuta automáticamente. Así, crear un post invalida la etiqueta Post, la lista de posts se marca obsoleta y se recarga sola, sin que escribas una línea de sincronización. Es la coherencia entre escritura y lectura resuelta de forma declarativa.

flowchart TD
A[useListarPostsQuery] --> B[cache etiquetada Post]
C[useCrearPostMutation] -->|invalidatesTags Post| B
B -->|etiqueta invalidada| D[refetch automatico]
D --> A
style B fill:#89b4fa,color:#11111b
style D fill:#a6e3a1,color:#11111b

Para que la escritura se sienta instantánea antes incluso de que el servidor responda, onQueryStarted permite una actualización optimista: parcheas la cache al vuelo con updateQueryData y, si el servidor falla, deshaces el parche con una sola llamada.

crearPost: builder.mutation<Post, NuevoPost>({
  query: (cuerpo) => ({ url: "posts", method: "POST", body: cuerpo }),
  async onQueryStarted(cuerpo, { dispatch, queryFulfilled }) {
    const parche = dispatch(
      api.util.updateQueryData("listarPosts", undefined, (borrador) => {
        borrador.push({ id: "temporal", titulo: cuerpo.titulo });
      }),
    );
    try {
      await queryFulfilled;
    } catch {
      parche.undo(); // el servidor fallo: revierte el optimismo
    }
  },
}),