Qué aprender que no caduque

Es probable que la mitad de las herramientas concretas que dominas hoy no se usen dentro de siete años. No porque sean malas, sino porque han sido buenas: lo que funciona se copia, se estandariza y termina absorbido por la capa de abajo, y entonces la herramienta que lo popularizó deja de tener razón de existir. Esa es la historia de las librerías de promises, de los empaquetadores de módulos y, según el resto de este nivel, de buena parte del andamiaje de estado que la industria construyó en la última década. Lo incómodo es que nadie te avisa de cuál de las cosas que estás aprendiendo hoy pertenece a esa mitad. Esta lección es un intento de darte ese aviso por adelantado: un criterio para distinguir, mientras aprendes, si lo que tienes delante es la estructura de un problema o la respuesta temporal de alguien a ese problema.

Dos clases de conocimiento con vidas medias distintas

Todo lo que sabes sobre estado cae en una de dos categorías, y distinguirlas es la habilidad central de esta lección.

La distinción no es una taxonomía académica: es una decisión de inversión. Tienes un número limitado de horas de estudio al año y cada una de ellas se puede colocar en un activo que se deprecia rápido o en uno que no se deprecia. Nadie te va a decir cuál es cuál en el momento de aprenderlo, así que necesitas un criterio propio para clasificar sobre la marcha.

El mecanismo es la respuesta concreta de una herramienta a un problema que tiene una única respuesta correcta. Cómo se declara una dependencia en un hook, qué comparador usa por defecto un selector, en qué orden se ejecutan los efectos de una librería, cómo se serializa un store para hidratarlo. Este conocimiento es real, útil y necesario para trabajar hoy, y tiene una vida media corta por una razón estructural: cuando un problema tiene respuesta única, esa respuesta acaba subiendo a la plataforma o bajando a un compilador, y la superficie que aprendiste desaparece con ella.

El invariante es la estructura del problema, que no depende de quién lo resuelva. Que un dato duplicado en dos sitios divergirá. Que derivar es más barato que sincronizar. Que un estado que puede representar lo imposible acabará representándolo. Que la propagación es un grafo y que el orden de recálculo importa. Este conocimiento sobrevive porque no es una respuesta, es una propiedad del terreno.

La confusión entre ambos no es casual ni inocente. La industria tiene incentivos para presentar mecanismo como si fuera sabiduría, porque una idea general no se puede vender, versionar ni poner en un curso, y una API sí. El resultado es que casi todo el material de aprendizaje disponible enseña la capa que caduca, y la capa que no caduca aparece de refilón, como justificación de una decisión concreta, en un párrafo que casi nadie lee.

Hay una forma cómoda de estimar la vida media de algo: mirar cuántas veces se ha reencarnado ya. Un patrón que ha aparecido con cuatro nombres distintos en tres décadas —la fuente única de verdad, la derivación, el flujo en un solo sentido— es casi seguro un invariante, porque el hecho de que siga reapareciendo bajo modas incompatibles demuestra que no era la moda lo que lo sostenía. Un patrón que solo existe dentro de una herramienta y no tiene equivalente en ninguna otra es casi seguro mecanismo.

flowchart TD
C[lo que aprendes hoy] --> M[mecanismo]
C --> I[invariante]
M --> M1[respuesta unica a un problema tecnico]
M1 --> M2[se copia entre librerias]
M2 --> M3[sube a la plataforma o baja al compilador]
M3 --> M4[caduca]
I --> I1[propiedad del problema]
I1 --> I2[independiente de la herramienta]
I2 --> I3[se reencarna con otro nombre]
I3 --> I4[no caduca]
style M4 fill:#f38ba8,color:#11111b
style I4 fill:#a6e3a1,color:#11111b

Una aclaración antes de seguir: la frontera entre ambas categorías no es una línea nítida sino un gradiente, y hay conocimiento intermedio que dura una década larga sin ser eterno. El modelo de componentes, por ejemplo, no es un invariante del estado y sin embargo lleva quince años en pie y probablemente durará otros diez. Lo importante no es clasificar cada cosa con precisión milimétrica, sino tener siempre una estimación aproximada de la vida útil de lo que estás aprendiendo.

La prueba práctica para clasificar algo es una sola pregunta: ¿esto se puede automatizar? Si la respuesta es sí, es mecanismo y alguien lo automatizará. La memoización manual se automatizó. El cableado de suscripciones se automatizó. La invalidación de cache se está automatizando. En cambio, decidir qué es una fuente de verdad, dónde poner la frontera de confianza o cuánta libertad de mutación merece una parte del producto no se puede automatizar, porque no son problemas técnicos con respuesta óptima sino juicios sobre un dominio.

Los invariantes del estado

Los cuatro anteriores son los que ya traías del track y conviene enunciarlos así, en una frase cada uno, porque un invariante que no cabe en una frase suele ser mecanismo disfrazado. A esos cuatro hay que sumar tres que operan en otra escala y que este nivel ha ido descubriendo.

Los tres que vienen se distinguen de los cuatro anteriores en el alcance: los primeros hablan de un dato y estos hablan de un sistema entero. Son también los que más tarde se aprenden, porque solo se hacen visibles cuando has visto fallar una arquitectura completa y no un componente suelto.

El quinto es que las clases de estado no son intercambiables. El estado local de una vista, el compartido de la aplicación, el que refleja algo remoto y el que vive en la dirección del navegador tienen ciclos de vida, dueños y modos de fallo distintos, y tratarlos con la misma herramienta es el error de arquitectura más común y más caro. Este invariante ha sobrevivido a todo porque no es técnico: es una observación sobre la naturaleza de los datos.

El sexto es que la frontera de confianza no es una frontera de distancia. Quién puede ver qué y quién puede escribir qué se decide por autoridad, y ninguna mejora en la infraestructura de sincronización va a cambiarlo. Cuando el dato se acerca al usuario, la frontera no se mueve: se vuelve más difícil de ver, que no es lo mismo.

Fíjate en una propiedad común de los siete: ninguno menciona una herramienta y ninguno se puede automatizar. No son consejos de rendimiento ni recetas de organización de carpetas, son afirmaciones sobre cómo se comportan los datos cuando hay más de un lector, más de un escritor o más de una copia. Por eso llevan intactos desde antes de que existiera la web y seguirán intactos después de la próxima generación de frameworks.

El séptimo es el más general y el que ordena a los demás: la mitad de lo que llamamos arquitectura de estado es compensación de latencia, y caduca cuando cambian los supuestos sobre la distancia. Saber hacer ese corte —qué existiría si el dato estuviera aquí y qué no— es lo que te permite predecir qué partes de tu conocimiento están en riesgo antes de que el riesgo se materialice.

Cómo se persigue lo que no caduca

Los invariantes no se aprenden leyendo documentación, porque la documentación describe mecanismo por definición. Ninguna guía oficial te va a explicar por qué su librería existe en términos que sobrevivan a su librería. Hay tres hábitos que sí producen ese conocimiento de forma fiable, y los tres tienen en común que son incómodos y lentos, que es probablemente la razón por la que funcionan.

El primero es implementar el primitivo, no solo usarlo. Escribir un sistema de señales de cincuenta líneas con seguimiento automático, orden topológico y agrupación enseña más sobre reactividad que años de usar cualquier librería, porque te obliga a tropezar con los problemas reales: el diamante, el efecto que se reengancha, la fuga del observador que nadie libera. Después de eso, ninguna librería de reactividad te resulta nueva; solo te resulta una variante.

// el ejercicio que fija los invariantes: el primitivo en su forma minima
let activo: Nodo | null = null
function leer(n: Nodo) {
  if (activo) { n.consumidores.add(activo); activo.fuentes.add(n) }
  if (n.sucio) recalcular(n)
  return n.valor
}
// lo dificil no es esto: es el orden de recalculo y no llamar dos veces al mismo nodo

Conviene añadir una condición al ejercicio para que sirva: no lo hagas mirando una implementación existente. La utilidad no está en el resultado sino en tropezar con los problemas por tu cuenta, porque un problema que resolviste tú deja una marca que un problema que leíste resuelto no deja. Compara después, cuando ya te hayas equivocado.

El segundo es leer el mismo problema en otra disciplina. Casi todos los invariantes del estado son teoremas prestados. La normalización y la desnormalización vienen de las bases de datos y explican por qué duplicar duele. La convergencia, la causalidad y la última escritura gana vienen de los sistemas distribuidos y explican todo lo que ocurre cuando hay dos réplicas. La evaluación perezosa y la transparencia referencial vienen de los lenguajes de programación y explican por qué una derivación pura se puede recalcular sin miedo. Quien ha visto el teorema en su forma original reconoce su reencarnación en cualquier framework a la primera.

El ejercicio tiene un efecto secundario valioso: te vuelve inmune al marketing. Después de haber peleado con el orden de recálculo y con la liberación de observadores, cualquier presentación que anuncie reactividad mágica te suena a lo que es, una elección concreta entre las tres o cuatro que ya conoces, con los mismos compromisos de siempre. La magia solo lo parece desde fuera.

El tercero es estudiar lo que fracasó y por qué. Las ideas muertas enseñan más que las vivas, porque en las vivas no sabes aún qué parte era esencial. Los enlaces bidireccionales fracasaron y de ese fracaso salió el flujo unidireccional. La detección de cambios por recorrido completo del árbol fracasó y de ahí salieron los signals. La transformación operacional perdió terreno frente a estructuras que convergen sin servidor coordinador. Cada fracaso es un invariante enunciado en negativo.

Hay un cuarto hábito, más difícil de practicar y más rentable que los tres anteriores: escribir tus propias conclusiones antes de leer las ajenas. Cuando te enfrentes a un problema de estado, anota qué crees que debería hacerse y por qué, y solo después mira cómo lo resolvió la librería que ibas a usar. Las veces que coincidan te confirman un invariante; las veces que difieran te enseñan una restricción que no habías visto. Consumir soluciones sin haber formulado antes la tuya produce familiaridad y muy poco criterio.

Conviene decir también qué no funciona, porque consume mucho tiempo. Coleccionar comparativas, seguir el ciclo de anuncios, probar cada herramienta nueva durante una tarde y acumular opiniones sobre cosas que nunca has llevado a producción produce la sensación de estar al día y no produce criterio, porque el criterio nace de haber pagado las consecuencias de una decisión durante meses. Estar informado y estar formado son actividades distintas y compiten por las mismas horas.

El protocolo para lo que venga

Cuando aparezca una herramienta de estado con un nombre que hoy no existe, no la evalúes por su demostración ni por quién la usa. Las demostraciones están construidas para lucir el caso que la herramienta resuelve mejor, y quién la usa es un dato sobre el problema de otro. Hazle tres preguntas, en este orden, y sabrás qué te promete y qué te cobra antes de leer el tutorial.

La primera es de coordenadas: cuánta propagación automática te da y cuánta disciplina de mutación te impone. Son los dos ejes del track y sitúan la herramienta en el mapa junto a todo lo que ya conoces. Una herramienta que no puedas situar en ese plano es casi siempre una herramienta que aún no has entendido.

Hay una variante rápida de esa primera pregunta que funciona sorprendentemente bien: intenta explicar la herramienta a alguien usando solo el vocabulario del track, sin ninguna palabra inventada por sus autores. Si lo consigues, entendiste el fondo y probablemente no aporta nada estructuralmente nuevo. Si no lo consigues, has encontrado o bien una idea genuinamente original, que es raro y valioso, o bien una capa de vocabulario que oculta una idea vieja, que es mucho más común.

La segunda es de compensación: qué supuesto la hace necesaria. Si la respuesta es un supuesto sobre la distancia de los datos, sobre el coste de una comparación o sobre una limitación concreta de un framework, estás ante una compensación, y su vida útil está atada a la de ese supuesto. Si la respuesta es un invariante del problema, estás ante algo más duradero.

La tercera es de absorción: ¿esto puede acabar en la plataforma o en un compilador? Si la herramienta hace algo mecánico, verificable y repetido por todos, la respuesta es sí y conviene adoptarla sin construir nada estructural encima. Si hace algo que exige juicio de dominio, no será absorbida y puedes apoyarte en ella con más confianza.

El protocolo no sirve para descartar herramientas, sirve para decidir cuánto peso soportan. Una herramienta absorbible es perfectamente adoptable siempre que la mantengas en la periferia y no dejes que su vocabulario se filtre a tus tipos de dominio ni a la forma de tus módulos. Una herramienta que resuelve un invariante puede ocupar el centro, porque su reemplazo futuro tendrá una forma parecida y la migración será una traducción y no una reescritura.

Aplícalo también hacia atrás, sobre lo que ya usas, porque ahí es donde da respuestas más incómodas. Buena parte del andamiaje que este nivel ha ido señalando —la cache de servidor, el estado de carga, la memoización manual— aprueba las tres preguntas como compensación absorbible, y sin embargo en muchas bases de código ocupa el centro de la arquitectura y define hasta el nombre de los ficheros. Esa es exactamente la situación que el protocolo intenta evitar en la próxima ronda.