Seguir aprendiendo: el código, los autores y hacia dónde va el estado

Un track termina; un oficio no. La diferencia entre alguien que hizo un curso sobre estado compartido y alguien que sabe de estado compartido es lo que ocurre en los dos años siguientes, y esa diferencia no la marca la cantidad de material consumido sino tres hábitos concretos: leer el código de las herramientas en lugar de solo su documentación, seguir a las personas que las construyeron en lugar de a quienes las resumen, y mirar hacia dónde se desplaza el problema en lugar de hacia dónde se desplaza el catálogo. Esta última lección no añade una técnica más al arsenal: entrega los tres hábitos con instrucciones suficientes para empezar esta misma semana, y termina con la única forma de plan de estudio que no caduca, que es la que se organiza alrededor de un problema y no alrededor de una herramienta.

Leer el código: una tarde bien invertida

Redux es, casi con seguridad, el mejor primer código fuente que un programador de interfaces puede leer entero. No porque sea el más importante, sino porque es pequeño, está escrito para ser leído, no depende de nada y resuelve un problema que ya entiendes por completo, que es la condición que convierte la lectura de código en aprendizaje en lugar de en desciframiento. El núcleo entero son unos pocos archivos, y la mayor parte de su volumen son comentarios y tipos.

El orden de lectura importa. Empieza por la composición de funciones, que se entiende en dos minutos y sin la cual el resto parece magia. Sigue por el ensamblado del middleware, que es el archivo más denso y más instructivo del proyecto: en él se ve por qué el dispatch que reciben las capas está deliberadamente cerrado sobre el dispatch final y qué clase de error produce llamarlo antes de tiempo. Continúa por el store, donde encontrarás decisiones defensivas que solo tienen sentido cuando ya te ha mordido el problema que evitan. Y termina por la composición de reducers, que es donde la inmutabilidad deja de ser un principio y se convierte en una comparación concreta.

// Reescribe estas dos piezas de memoria antes de leer el original.
// Si te salen, has entendido el nucleo entero.
const compose = (...fns) => fns.reduce((a, b) => (...args) => a(b(...args)))

function applyMiddleware(...middlewares) {
  return (crear) => (reducer, inicial) => {
    const store = crear(reducer, inicial)
    let dispatch = () => { throw new Error('despacho durante la construccion') }
    const api = { getState: store.getState, dispatch: (a, ...r) => dispatch(a, ...r) }
    const cadena = middlewares.map((m) => m(api))
    dispatch = compose(...cadena)(store.dispatch)
    return { ...store, dispatch }
  }
}

Cuando termines con el núcleo, el siguiente escalón natural es el enlace con React, que es donde vive la parte difícil de verdad: cómo se evita que dos componentes vean estados distintos del mismo dato durante un render concurrente. Ahí aparece el hook que el propio React acabó incorporando para resolver ese problema en general, y entender por qué existe explica una década de sutilezas sobre suscripciones externas. El tercer escalón es la librería de selectores memoizados, corta y llena de decisiones de diseño discutibles y bien discutidas, sobre todo en lo relativo al tamaño de la cache y a las claves débiles.

Los escritos de quienes lo construyeron

Una peculiaridad de este ecosistema, poco frecuente en el oficio, es que sus autores escribieron mucho, escribieron bien y escribieron sobre todo cuando se habían equivocado. Leer esos textos cambia la relación con las herramientas porque devuelve las decisiones a su contexto: casi todo lo que hoy parece arbitrario fue una respuesta razonada a una restricción concreta que se puede reconstruir.

Hay dos textos que conviene destacar por lo que enseñan sobre el oficio más que sobre la librería. El primero es el ensayo en el que el propio creador de Redux argumenta que probablemente no lo necesitas, publicado cuando su adopción estaba en el punto más alto. El segundo es la serie de artículos del mantenedor actual explicando por qué se abandonó el patrón de conexión por componentes de orden superior, por qué se adoptó Immer pese a la doctrina de la inmutabilidad manual y por qué se acabó incluyendo una capa de cache dentro de una librería que decía no ser una librería de datos. Los tres cambios contradicen posiciones defendidas antes por el mismo proyecto, y están documentados con sus motivos.

Hacia dónde va el estado en la web

Tres corrientes están moviendo el problema, y ninguna de las tres es una librería nueva. Conviene mirarlas por separado porque afectan a capas distintas del modelo mental y se pueden combinar entre sí.

flowchart TD
HOY[estado en el cliente en 2026] --> A[componentes y acciones de servidor]
HOY --> B[signals como capa de deteccion]
HOY --> C[motores de sincronizacion y datos locales]
A --> A1[menos cache en el cliente y mas datos en el render]
B --> B1[misma arquitectura con notificacion mas fina]
C --> C1[el cliente vuelve a ser dueno de la verdad]
C1 --> D[reaparece el problema original con otra escala]
style HOY fill:#89b4fa,color:#11111b
style D fill:#f38ba8,color:#11111b

La primera corriente es el desplazamiento del estado hacia el servidor. Los componentes de servidor y las acciones de servidor se llevan una parte del trabajo que antes exigía cache en el cliente: si los datos llegan ya resueltos en el render y la mutación se declara como una función que corre en el servidor, desaparecen muchas de las razones para tener una copia local con su ciclo de vida. Lo que queda en el cliente después de ese desplazamiento es, precisamente, lo que las lecciones anteriores llamaban estado de cliente compartido, más las actualizaciones optimistas y las transiciones pendientes que el propio framework ha empezado a modelar con hooks propios.

La segunda corriente son las signals, que se han extendido a la vez por casi todos los ecosistemas y tienen incluso una propuesta de estandarización en el lenguaje. Es importante leerlas por lo que son: un cambio en la capa de detección de cambios y de notificación, no un sustituto de la arquitectura. Una signal resuelve mejor el problema de enterarse de que algo cambió con grano fino; no dice nada sobre quién posee el dato, quién puede escribirlo ni dónde viven los efectos. Por eso siguen apareciendo stores construidos encima de signals, y por eso quien las interpretó como el fin de los gestores de estado lleva tiempo desconcertado.

La tercera es la más interesante a largo plazo y la menos comentada: los motores de sincronización y las arquitecturas con datos locales, con sus estructuras de datos que convergen sin conflicto y sus bases replicadas en el navegador. Su promesa es que la aplicación escriba siempre en local y la sincronización ocurra por debajo, lo que devuelve al cliente la propiedad de la verdad que la corriente del servidor le estaba quitando. Si esa promesa se cumple a escala, el problema del estado no desaparece: vuelve con más fuerza, porque un cliente que es dueño de datos compartidos con otros clientes necesita exactamente lo que este track ha estado enseñando —cambios como valores, transiciones puras, historial inspeccionable— y lo necesita con garantías más duras.

Un plan de estudio que no caduca

Un plan organizado por herramientas caduca con ellas; uno organizado por problemas dura lo que dure el problema, que en este caso es indefinido. La propuesta de cierre es un plan de cuatro movimientos, pensado para repetirse en ciclo y no para completarse una vez.

// El ejercicio del segundo movimiento, con sus dos trampas marcadas.
function memoizarUno<A extends unknown[], R>(fn: (...a: A) => R, iguales = Object.is) {
  let ultimos: A | null = null
  let salida: R
  return (...args: A): R => {
    const mismo = ultimos !== null
      && ultimos.length === args.length
      && args.every((v, i) => iguales(v, ultimos![i])) // trampa 1: comparar por posicion
    if (mismo) return salida
    ultimos = args
    salida = fn(...args)   // trampa 2: cache de tamano uno, inutil si alternas argumentos
    return salida
  }
}

El movimiento más infravalorado de los cuatro es el segundo. Implementar un store con suscripciones, un ensamblado de middleware y un selector memoizado ocupa una tarde y produce una comprensión que ninguna cantidad de lectura consigue, porque obliga a tomar todas las decisiones pequeñas que la documentación omite: qué pasa si alguien se desuscribe durante la notificación, qué se compara y con qué profundidad, cuándo se invalida la cache. Esas decisiones pequeñas son, casi siempre, el contenido real de las librerías que usamos.