Qué debe vivir en el estado
El estado del core no es «todo el estado»: es lo que tiene consecuencias y sobrevive a un recargado. Cuatro criterios para decidir, y los dos errores simétricos de meter de más y de menos.
Los cuatro criterios
Las tres capas
Con esos criterios, el estado de una aplicación se reparte en tres sitios y conviene tenerlos nombrados:
Los dos errores
Meter de más. El síntoma es un comando por cada dato que la interfaz quiere leer —el exceso del nivel 13.5— y un core que sabe qué pestaña está abierta. La causa suele ser una regla mal recordada: «el core es el dueño del estado» se convierte en «todo el estado va al core».
El coste: cada lectura cruza el puente, el core se llena de accesores, y la interfaz no puede cambiar su estructura sin tocar Rust.
Meter de menos. El síntoma es que un recargado de la webview rompe cosas, o que dos ventanas se contradicen. La causa suele ser la comodidad: el frontend es donde el ciclo es más rápido.
El coste: es el error clásico del nivel 12.5, con sus tres consecuencias —se rompe si la ventana se cierra, se pierde al recargar, y acaba en dos copias—.
La prueba que caza el segundo en diez segundos: recarga la webview y comprueba qué se rompe. Lo que se rompa estaba en la capa equivocada.
Un caso que confunde: la caché
Merece nombrarlo porque la respuesta no es evidente. Una caché de lo que el core ya calculó —miniaturas, resultados de búsqueda, un índice— cumple el criterio 3 y no los otros tres.
La respuesta: va en el core, y con una diferencia importante respecto al resto del estado. Perderla no rompe nada: solo hace que la próxima vez cueste más. Eso tiene dos consecuencias prácticas:
- No hace falta protegerla con el mismo cuidado. Un fallo al escribir en la caché no debe hacer fallar la operación.
- Se puede vaciar cuando haga falta, por memoria o por edad, sin preguntar a nadie.
Distinguir «estado que si se pierde rompe» de «estado que si se pierde solo cuesta» es útil en todas las capas, y evita tratar una caché con la ceremonia de una sesión.