Transformaciones: transformResponse y datos derivados

Ningún backend devuelve exactamente la forma que tu interfaz quiere. Devuelve envoltorios con metadatos, fechas como cadenas, campos con nombres heredados de una base de datos que nadie recuerda haber diseñado, y colecciones planas donde tú necesitas índices. La pregunta no es si habrá una transformación, sino dónde vivirá: repartida por los componentes que la aplican cada uno a su manera, o concentrada en una frontera única y explícita. RTK Query ofrece esa frontera en dos lugares complementarios y decidir qué va en cada uno es la competencia real de esta lección. transformResponse transforma antes de guardar, y lo que produce es lo que la cache contiene; los selectores transforman después de leer, y lo que producen es efímero. La diferencia entre ambos no es de rendimiento sino de ontología: uno decide qué es verdad en tu aplicación, el otro decide cómo mirarla.

transformResponse: la frontera anticorrupción

transformResponse se ejecuta una sola vez, entre la respuesta del baseQuery y el almacenamiento en la cache. Recibe la carga cruda, los metadatos de la respuesta —cabeceras y objeto de respuesta original, útiles para paginación— y el argumento del endpoint. Lo que devuelva es literalmente lo que quedará guardado, lo que verán los hooks, lo que recibirá providesTags y lo que parchearán las actualizaciones optimistas de la lección siguiente. Esa centralidad es la razón por la que conviene tratarlo con el respeto de una frontera arquitectónica y no como un ayudante de conveniencia.

interface PostRemoto {
  post_id: number;
  post_title: string;
  created_at: string;
  author: { author_id: number; author_name: string };
}

interface Post { id: string; titulo: string; creadoEn: number; autorId: string; autorNombre: string }

const aPost = (r: PostRemoto): Post => ({
  id: String(r.post_id),
  titulo: r.post_title,
  creadoEn: Date.parse(r.created_at),
  autorId: String(r.author.author_id),
  autorNombre: r.author.author_name,
});

Con esa función, el endpoint se limita a declarar la traducción, y a partir de ese punto ningún componente vuelve a ver jamás un nombre de campo del backend. El beneficio no es estético: es que el día que el servidor renombre un campo o cambie el formato de fecha, el número de ficheros que hay que tocar es exactamente uno.

listarPosts: builder.query<Post[], void>({
  query: () => "posts",
  transformResponse: (crudo: { data: PostRemoto[] }) => crudo.data.map(aPost),
  transformErrorResponse: (error) => ({
    codigo: error.status,
    mensaje: "no se pudieron cargar los posts",
  }),
  providesTags: (r) => [
    ...(r ?? []).map((p) => ({ type: "Post" as const, id: p.id })),
    { type: "Post" as const, id: "LIST" },
  ],
}),

transformErrorResponse es la mitad que casi nadie usa y que casi todo el mundo necesita. Sin ella, cada componente recibe la estructura de error cruda del transporte y termina inspeccionando códigos HTTP en la capa de presentación, que es exactamente donde no deben vivir. Normalizar el fallo a un tipo propio —un código de dominio y un mensaje ya decidido— hace que la UI trate errores sin saber que existe HTTP.

Normalizar dentro de la cache

Que RTK Query cachee no significa que la forma cacheada sea buena. Una consulta que devuelve un array de cien posts guarda un array, y toda búsqueda por identificador dentro de ese array es lineal, toda actualización puntual exige reconstruirlo entero y toda referencia cruzada desde otra entrada duplica los datos. createEntityAdapter, que ya conoces del Nivel 5, encaja aquí sin fricción porque su salida —un diccionario de entidades más un array de identificadores— es un valor serializable perfectamente válido como contenido de cache.

import { createEntityAdapter } from "@reduxjs/toolkit";

const adaptador = createEntityAdapter<Post>({ sortComparer: (a, b) => b.creadoEn - a.creadoEn });
const estadoInicial = adaptador.getInitialState();

listarPosts: builder.query<ReturnType<typeof adaptador.getInitialState>, void>({
  query: () => "posts",
  transformResponse: (crudo: { data: PostRemoto[] }) =>
    adaptador.setAll(estadoInicial, crudo.data.map(aPost)),
  providesTags: (r) => [
    ...(r?.ids ?? []).map((id) => ({ type: "Post" as const, id: String(id) })),
    { type: "Post" as const, id: "LIST" },
  ],
}),

Nótese que las etiquetas ahora se derivan del array de identificadores en lugar de recorrer entidades, lo cual es más barato y más directo. Y nótese también la sutileza del sortComparer: el adaptador mantiene el orden en el array de identificadores, de modo que el orden es un dato explícito de la estructura y no una propiedad accidental de cómo llegó la respuesta. Esto contradice solo en apariencia la advertencia anterior sobre no ordenar en transformResponse; lo que el adaptador fija es un orden canónico de almacenamiento, no el orden de una vista concreta, y cualquier vista sigue libre de reordenar al leer.

Selectores sobre entradas de cache

Hay dos vías para leer una entrada de cache con transformación, y confundirlas cuesta re-renderizados. La primera es selectFromResult, una opción del propio hook que aplica una función al estado de la consulta y hace que el componente solo se re-renderice cuando el resultado de esa función cambia por comparación superficial. Es la vía correcta cuando una vista quiere una porción diminuta de una entrada grande.

function TituloDePost({ id }: { id: string }) {
  const { titulo } = useListarPostsQuery(undefined, {
    selectFromResult: ({ data }) => ({ titulo: data?.entities[id]?.titulo }),
  });
  return <h3>{titulo ?? "sin titulo"}</h3>;
}

La segunda vía es api.endpoints.listarPosts.select, que devuelve un selector del store estándar y por tanto componible con createSelector de Reselect. Esta es la vía cuando la derivación es cara y se comparte entre varios componentes, o cuando hay que cruzar una entrada de cache con estado de cliente que vive en otro slice.

import { createSelector } from "@reduxjs/toolkit";

const seleccionarLista = api.endpoints.listarPosts.select();

export const seleccionarPostsVisibles = createSelector(
  [seleccionarLista, (estado: RootState) => estado.filtros.autorId],
  (resultado, autorId) => {
    const estado = resultado.data;
    if (!estado) return [];
    return estado.ids
      .map((id) => estado.entities[id]!)
      .filter((p) => autorId === null || p.autorId === autorId);
  },
);

Este selector expresa con claridad la división de trabajo del nivel: la cache guarda todos los posts normalizados, el slice de cliente guarda qué autor está filtrado, y el cruce de ambos no se guarda en ninguna parte porque se computa. Nada en el store contiene la lista visible, y esa ausencia es una decisión de diseño, no un olvido.

flowchart LR
A[respuesta cruda del backend] --> B[transformResponse]
B --> C[entrada de cache normalizada]
C --> D[selectFromResult para una porcion]
C --> E[createSelector con estado de cliente]
E --> F[vista derivada y efimera]
D --> F
style B fill:#fab387,color:#11111b
style C fill:#89b4fa,color:#11111b
style F fill:#a6e3a1,color:#11111b

Dónde no debe vivir un dato derivado

Queda una tercera opción que el diagrama omite deliberadamente porque es la equivocada: guardar el dato derivado. Escribir en un slice el recuento de posts visibles, o el mapa de posts por autor, o la lista ya filtrada, es tentador porque parece ahorrar cómputo. Lo que en realidad hace es crear una segunda copia de una verdad que ya existía, y con ella la obligación permanente de mantener ambas sincronizadas ante cualquier invalidación, cualquier actualización optimista y cualquier refresco en segundo plano. El coste de recomputar un filtro sobre unos cientos de elementos es despreciable; el coste de un contador que miente después de un refetch es un bug que nadie reproduce.