useSnapshot: la foto inmutable y su seguimiento

Si la lección anterior explicó cómo Valtio sabe que algo cambió, esta explica cómo decide a quién le importa. Y la respuesta es más elegante de lo que sugiere la API: useSnapshot no devuelve el estado, devuelve una fotografía congelada envuelta en un segundo proxy cuya única misión es apuntar qué propiedades leyó tu componente mientras se renderizaba. Ese cuaderno de accesos es el selector que nunca escribiste. Cuando llega un cambio, la librería contrasta lo que cambió con lo que ese componente leyó de verdad y decide en consecuencia. Entender este segundo proxy —distinto del de escritura, con un propósito opuesto— es lo que transforma la regla lee del snapshot, escribe en el proxy de superstición en teorema.

Qué es una instantánea

Una instantánea es el estado del proxy en un instante, convertido en una estructura inmutable y congelada. No es una copia profunda: las ramas que no cambiaron desde la foto anterior se reutilizan tal cual, con la misma identidad, y solo las que cambiaron reciben objetos nuevos. Esa compartición estructural es lo que hace viable tomar fotos continuamente sin arruinar el rendimiento, y también lo que hace fiable comparar dos fotos por referencia.

import { proxy, snapshot } from 'valtio'

const estado = proxy({ perfil: { nombre: 'Ada' }, contador: 0 })

const a = snapshot(estado)
estado.contador += 1
const b = snapshot(estado)

a === b            // false: la raiz cambio
a.perfil === b.perfil  // true: esa rama no fue tocada

Ese par de comparaciones concentra toda la idea. La raíz cambió porque el contador vive en ella, pero perfil conservó su identidad porque nadie lo tocó, y por tanto cualquier consumidor que solo mire perfil puede concluir en una comparación de referencias que no tiene nada que hacer. Es exactamente la propiedad que la ortodoxia inmutable perseguía con reductores escritos a mano, obtenida aquí como subproducto del motor de versiones.

La instantánea está congelada de verdad, no por convención. Intentar mutarla no hace nada en modo laxo y lanza en modo estricto, y esa dureza es deliberada: si dos componentes pudieran alterar sus respectivas fotos, dejarían de ser fotografías del mismo estado y la coherencia entre vistas se perdería. La inmutabilidad del snapshot no es una precaución estilística, es el mecanismo que garantiza que todos los consumidores de un mismo instante vean lo mismo.

El cuaderno de accesos

Aquí aparece el segundo proxy. useSnapshot toma la instantánea congelada y la envuelve en un proxy de solo lectura cuya trampa de acceso anota cada propiedad que el componente consulta durante el render. Al terminar el render, la librería tiene una lista precisa de lo que ese componente miró: no lo que declaró mirar, sino lo que miró.

import { useSnapshot } from 'valtio'
import { estado } from './store'

function Nombre() {
  const snap = useSnapshot(estado)
  return <span>{snap.perfil.nombre}</span>
}

function Contador() {
  const snap = useSnapshot(estado)
  return <button onClick={() => (estado.contador += 1)}>{snap.contador}</button>
}

Al pulsar el botón, Contador se re-renderiza y Nombre no. No porque alguien lo haya declarado, sino porque el cuaderno de Nombre contiene solo la ruta hacia perfil.nombre, y esa rama conservó su identidad en la nueva foto. El seguimiento es de rutas, no de objetos completos: acceder a snap.perfil.nombre registra el camino, de modo que cambiar perfil.apellido tampoco despierta a Nombre, aunque perfil sea el mismo objeto padre.

flowchart LR
P[proxy mutable] -->|mutacion agrupada| S[instantanea congelada]
S --> T[proxy de seguimiento]
T -->|registra rutas leidas| C[cuaderno de accesos]
M[cambio nuevo] --> D{alguna ruta leida cambio?}
C --> D
D -->|si| R[re-render]
D -->|no| N[nada que hacer]
style T fill:#f9e2af,color:#11111b
style C fill:#94e2d5,color:#11111b
style R fill:#89b4fa,color:#11111b
style N fill:#a6e3a1,color:#11111b

Conviene ver el contraste con la alternativa explícita para calibrar qué se gana. En Zustand el equivalente exige nombrar la dependencia y, si el selector devuelve un objeto nuevo en cada llamada, añadir una función de igualdad para que la comparación no falle siempre:

// explicito: la dependencia es codigo que alguien escribio y puede olvidar
const nombre = useStore((s) => s.perfil.nombre)

// observado: la dependencia es un hecho del render, no una declaracion
const snap = useSnapshot(estado)
const otroNombre = snap.perfil.nombre

La versión observada no puede desincronizarse de lo que el componente usa, porque es literalmente lo que el componente usó. La versión explícita puede quedarse obsoleta cuando alguien cambia el cuerpo del render y olvida el selector, que es uno de los errores más frecuentes y más silenciosos del oficio. A cambio, la explícita se lee en una revisión de código y la observada no.

El módulo que hace este trabajo, proxy-compare, se publica aparte y merece atención propia: compara dos objetos guiado por un registro de accesos, en vez de comparar todo con todo. Esa inversión es la clave del rendimiento, porque el coste de decidir si un componente debe actualizarse deja de depender del tamaño del estado y pasa a depender del tamaño de lo que ese componente leyó, que casi siempre es diminuto. Un estado con diez mil nodos y un componente que lee tres campos cuesta lo mismo que un estado con diez nodos.

Los cuatro modos de romper el seguimiento

El seguimiento es automático, y por eso mismo es silencioso cuando se rompe. No hay error, no hay aviso: simplemente el componente se actualiza más de lo necesario o deja de actualizarse. Los modos de fallo son pocos y reconocibles.

El tercer caso es el más sutil porque parece inocente. Escribir una desestructuración amplia de la instantánea al principio del componente hace que el proxy de seguimiento registre todas esas propiedades, aunque el render acabe usando una sola por culpa de una condición. El seguimiento es fiel a lo que ocurrió, no a lo que se usó al final, así que la disciplina consiste en tocar la foto lo más tarde y lo más fino posible.

El cuarto caso invita a un matiz importante sobre la naturaleza del cuaderno: se reconstruye en cada render. Si un componente lee un campo solo cuando una bandera está activa, mientras la bandera esté apagada ese campo no figura en el cuaderno y sus cambios no despiertan al componente. Eso es correcto —no lo estaba usando— pero puede parecer un bug si esperabas una suscripción estática. Pensar en el cuaderno como algo vivo, que refleja el último render y no un contrato permanente, disuelve la confusión.

La regla de oro como teorema

Con el mecanismo delante, la regla de oro deja de ser una norma arbitraria. Lee de la instantánea porque solo la instantánea pasa por el proxy de seguimiento y solo así el sistema sabe qué te importa. Escribe en el proxy porque solo el proxy tiene trampas de escritura y solo así el sistema se entera de que algo cambió. Cada mitad de la regla es la consecuencia directa de qué mecanismo vive en cada objeto, y por eso quien entiende los dos proxies no necesita memorizar nada: deduce la regla cada vez que la necesita.

Hay además una consecuencia sobre el paso de propiedades entre componentes que conviene anticipar. Si un componente padre lee la instantánea y pasa un trozo a un hijo como propiedad, la dependencia queda registrada en el padre y no en el hijo, de modo que cualquier cambio en ese trozo re-renderiza a los dos. Cuando el hijo es caro, la solución idiomática es que sea él quien llame a useSnapshot sobre el mismo proxy y lea lo que necesita, en vez de recibirlo. El patrón invierte el consejo habitual de elevar el estado: aquí conviene bajar la lectura hasta donde se usa, porque la lectura es la suscripción y suscribirse arriba suscribe a todo el subárbol.

// menos fino: la dependencia vive en el padre y arrastra al hijo
function Padre() {
  const snap = useSnapshot(estado)
  return <Hijo nombre={snap.perfil.nombre} />
}

// mas fino: cada componente registra solo lo que mira
function Hijo() {
  const snap = useSnapshot(estado)
  return <span>{snap.perfil.nombre}</span>
}

Queda una pregunta natural que conviene responder para cerrar el modelo. Si el seguimiento es tan bueno, por qué existen librerías que exigen selectores explícitos. Porque la explicitud tiene virtudes que la observación no da: un selector es una función nombrada, testeable, reutilizable y visible en el código, mientras que un cuaderno de accesos es un hecho de tiempo de ejecución que nadie puede leer en una revisión de código. Ambos enfoques compran cosas distintas, y la lección quinta de este nivel pone esa comparación por escrito con criterios honestos.