reselect y createSelector: memoizar la derivación

La lección anterior terminó en una grieta: un selector derivado que filtra o proyecta crea una referencia nueva en cada llamada, y esa referencia nueva engaña a useSelector, que cree que el dato cambió y re-renderiza sin motivo. A eso se suma el coste bruto de recalcular una derivación cara —ordenar, agrupar, agregar— cada vez que cualquier parte del store se toca. reselect, la librería de memoización que Redux Toolkit trae incluida, ataca los dos problemas con una sola idea: si las entradas de un cálculo no han cambiado, no lo recalcules y devuelve el mismo resultado de antes, con su misma referencia. Memoizar no es solo ir más rápido; es convertir el concepto vago de igualdad en la moneda exacta que React usa para decidir qué trabajo puede saltarse.

Por qué memoizar: los dos costes

Conviene separar los dos males que la memoización cura, porque se confunden. El primero es de rendimiento: una derivación cara —ordenar mil filas, agrupar, calcular totales— se ejecuta en cada render aunque sus datos de entrada no hayan cambiado. El segundo es de identidad: aunque el cálculo fuera barato, si devuelve un objeto o array nuevo, esa referencia distinta hace que useSelector, React.memo y cualquier comparación por === crean que algo cambió. Memoizar resuelve ambos de un golpe: cuando las entradas son las mismas, no se recalcula (cura el rendimiento) y se devuelve el resultado anterior con su referencia intacta (cura la identidad).

El segundo coste es el más insidioso porque es invisible en pantalla: nada se ve mal, pero cada despacho —venga de donde venga, aunque no toque tus datos— repinta componentes que no cambiaron. En una lista larga o un dashboard, esa cascada silenciosa de renders es la causa número uno de una interfaz que se siente lenta sin que ningún cálculo concreto parezca culpable.

createSelector: entradas y función de resultado

createSelector recibe una lista de selectores de entrada y una función de resultado. Ejecuta primero los selectores de entrada; solo si alguno devuelve una referencia distinta a la de la llamada anterior vuelve a ejecutar la función de resultado. Si todas las entradas son idénticas, la función de resultado ni se llama: devuelve el valor cacheado.

import { createSelector } from '@reduxjs/toolkit' // reselect va incluido

const selectTodos = (s: RootState) => s.todos.entidades
const selectFiltro = (s: RootState) => s.todos.filtro

// Entradas + funcion de resultado. La funcion de resultado solo se
// re-ejecuta si selectTodos o selectFiltro cambian de REFERENCIA.
export const selectVisibles = createSelector(
  [selectTodos, selectFiltro],
  (todos, filtro) => Object.values(todos).filter((t) => t.estado === filtro),
)

// Una entrada puede leer argumentos ademas del estado (props del componente).
export const selectPorPrioridad = createSelector(
  [selectTodos, (_s: RootState, min: number) => min],
  (todos, min) => Object.values(todos).filter((t) => t.prioridad >= min),
)

flowchart TD
A[cambio en el store] --> B[ejecutar selectores de entrada]
B --> C[alguna entrada cambio de referencia?]
C -->|no| D[devolver resultado memoizado]
C -->|si| E[ejecutar funcion de resultado]
E --> F[guardar nuevo resultado en cache]
style D fill:#a6e3a1,color:#11111b
style E fill:#fab387,color:#11111b

De aquí se deduce la regla de oro de diseñar buenos selectores memoizados: las entradas deben ser lo más estrechas y estables posible. Si un selector de entrada devuelve una rama que apenas cambia, la función de resultado casi nunca corre; si devuelve todo el estado, o peor, un objeto construido al vuelo, la caché no acierta jamás y la memoización no sirve de nada.

La memoización por defecto en 2026: weakMapMemoize

Durante años, reselect memoizaba con una caché de tamaño uno: recordaba solo la última combinación de entradas. Bastaba llamar al mismo selector alternando dos argumentos para que la caché se destruyera en cada llamada —el temido cache thrashing—. Desde reselect 5, incluido en Redux Toolkit 2.0, el memoizador por defecto es weakMapMemoize: cachea por identidad de las entradas usando WeakMap anidados, con una caché prácticamente ilimitada y recolectada sola por el recolector de basura. En la práctica, el mismo selector llamado con muchos argumentos distintos mantiene un resultado memoizado para cada combinación, sin que tú gestiones nada.

El detalle de que use WeakMap no es un tecnicismo: significa que las claves de la caché son referencias débiles, así que cuando un objeto de entrada deja de existir en el resto del programa, su entrada en la caché se libera sola. No hay fuga de memoria ni límite que ajustar; la caché crece y mengua siguiendo la vida de los datos que memoiza. Esa es la razón por la que pudo convertirse en el defecto sin obligar a nadie a preocuparse por su tamaño.

El problema clásico, el factory y afinar el memoizador

Con la vieja caché de tamaño uno, un selector parametrizado compartido —selectTodoPorId(state, id) usado por muchos componentes con id distintos a la vez— se autodestruía en cada render. La solución idiomática era la selector factory: una función que fabrica una instancia nueva del selector por componente, memoizada con useMemo, de modo que cada uno tuviera su propia caché.

import { createSelector, lruMemoize } from '@reduxjs/toolkit'

// Patron factory: una instancia de selector por consumidor.
const makeSelectTotalPorCategoria = () =>
  createSelector(
    [(s: RootState) => s.items, (_s: RootState, cat: string) => cat],
    (items, cat) => items.filter((i) => i.cat === cat).length,
  )

// Afinar: volver al memoizador clasico de tamano uno, con LRU explicito.
const selectCaro = createSelector(
  [selectA, selectB],
  (a, b) => calcular(a, b),
  { memoize: lruMemoize, memoizeOptions: { maxSize: 10 } },
)

En 2026, weakMapMemoize hace innecesario el factory en la mayoría de los casos: la caché por identidad ya distingue cada id sin que tú fabriques instancias. Pero el patrón sigue siendo parte de la cultura del ecosistema, aparece en código que mantendrás y sigue siendo la respuesta cuando necesitas controlar el ciclo de vida de la caché a mano. Para afinar más allá del defecto, createSelector acepta un tercer argumento con memoize, argsMemoize y memoizeOptions, y createSelectorCreator te deja fabricar tu propia variante —por ejemplo, una que compare las entradas por igualdad profunda cuando de verdad no puedas estabilizar sus referencias—.