Patrones de datos derivados: componer sin recomputar

Las cuatro lecciones anteriores fueron piezas; esta las ensambla en una imagen única. Un estado normalizado guarda la verdad una sola vez; unos selectores base la leen preservando referencias; unos selectores derivados y memoizados computan sobre ellos las proyecciones que la interfaz necesita; y esos derivados se componen entre sí formando un grafo de dependencias que convierte la interfaz en una función pura del estado. Es el ideal de la programación funcional-reactiva llevado a la gestión de estado: no guardas lo que puedes calcular, y calculas a través de una red de derivaciones que solo recomputa lo que un cambio real toca. Pero un ideal llevado sin criterio se vuelve dogma, y la parte más valiosa de esta lección no es cómo componer selectores, sino cuándo no hacerlo: cuándo memoizar es sabiduría y cuándo es complejidad disfrazada de rigor.

Componer selectores en un grafo

La verdadera potencia de createSelector no está en un selector aislado, sino en que la salida de uno puede ser la entrada de otro. Así se construyen cadenas de derivación —el estado derivado en cascada del Nivel 6— donde cada eslabón memoiza su parte y solo recomputa cuando su entrada concreta cambia. El grafo resultante se recorre en orden topológico y es glitch-free por construcción (Nivel 8): un cambio se propaga por las aristas que dependen de él y por ninguna más.

// Cada derivado se apoya en el anterior: un grafo de dependencias.
const selectVisibles = createSelector(
  [selectTareas, selectFiltro],
  (tareas, filtro) => tareas.filter((t) => t.estado === filtro),
)

const selectVisiblesOrdenadas = createSelector(
  [selectVisibles, selectOrden],           // reutiliza el derivado de arriba
  (visibles, orden) => [...visibles].sort(orden),
)

// createStructuredSelector: agrupa varios en un objeto de resultado.
const selectVistaLista = createStructuredSelector({
  items: selectVisiblesOrdenadas,
  total: selectNumTareas,
})

flowchart TD
E1[selectTareas] --> D1[selectVisibles]
F1[selectFiltro] --> D1
D1 --> D2[selectVisiblesOrdenadas]
O1[selectOrden] --> D2
D2 --> UI[componente lista]
style D1 fill:#89b4fa,color:#11111b
style D2 fill:#cba6f7,color:#11111b
style UI fill:#a6e3a1,color:#11111b

Componer así tiene una ventaja de diseño más allá del rendimiento: cada selector es pequeño, tiene un solo propósito, se prueba en aislamiento y se reutiliza. Si diez vistas necesitan las tareas visibles, todas parten del mismo selectVisibles y comparten su caché.

Evitar recomputar: la granularidad de las entradas

Un grafo de selectores solo es eficiente si sus entradas están bien diseñadas. La regla, ya insinuada en la lección 2, se vuelve central aquí: cada selector debe recibir las entradas más estrechas que su cálculo necesita, y ni una más. Un selector cuya función de resultado depende de entities pero recibe como entrada todo el slice recomputará cuando cambie cualquier campo del slice, aunque entities no se haya tocado. Y el antipatrón más costoso es la entrada que fabrica una referencia nueva en cada llamada, que ya vimos: rompe la memoización de raíz.

// Antipatron: la entrada crea un objeto nuevo cada vez ->
// nunca acierta en cache y la funcion de resultado corre siempre.
const malo = createSelector(
  [(s: RootState) => ({ a: s.a, b: s.b })], // referencia nueva en cada llamada
  (par) => calcular(par.a, par.b),
)

// Correcto: entradas estrechas y estables, cada una su propio selector.
const bueno = createSelector(
  [(s: RootState) => s.a, (s: RootState) => s.b],
  (a, b) => calcular(a, b),
)

Aquí es donde la normalización de la lección 3 rinde su dividendo final: como los updates son locales, las ramas no tocadas conservan su referencia, y un grafo de selectores bien diseñado sobre estado normalizado recomputa asombrosamente poco, porque casi todas sus entradas siguen siendo idénticas casi siempre.

Derivar, no guardar

Hay una tentación recurrente: en lugar de derivar un valor con un selector, guardarlo ya calculado en el store —el total del carrito, la lista filtrada, el contador—. Es casi siempre un error, y la razón conecta con el corazón del track: guardar datos derivados crea una segunda fuente de verdad que hay que mantener sincronizada con la primera, y cada punto de sincronización es un bug esperando a que alguien actualice una y olvide la otra. Un dato derivado por un selector, en cambio, es incapaz de desincronizarse: se recalcula de la fuente cada vez que la fuente cambia, y su corrección es una propiedad de la función, no una responsabilidad del programador.

El equilibrio con la simplicidad

Y llegamos a la lección que separa al que conoce reselect del que lo domina: no todo selector merece createSelector. La memoización tiene un coste —cierres, cachés, comparaciones en cada llamada— y envolver en createSelector una lectura trivial o un cálculo barato que devuelve un primitivo añade complejidad sin comprar nada. Un selector state => state.usuario.nombre no necesita memoización: devuelve un string, ya estable por valor. Memoizar por reflejo es tan error como no memoizar por descuido; ambos nacen de aplicar una regla sin entender qué problema resuelve.