La regla práctica: minimiza la fuente, maximiza lo derivado

Todo el nivel converge en una sola heurística, tan simple de enunciar como difícil de sostener bajo presión: minimiza el estado fuente y maximiza el derivado. El estado que almacenas es un pasivo —cada dato guardado es un invariante que mantener, una copia que sincronizar, un camino de mutación que no olvidar—, mientras que la derivación es un activo que se paga una vez y no puede quedar obsoleto. Cuando dudes entre guardar un dato o calcularlo, la respuesta por defecto es calcularlo, y solo guardas lo que no puedes deducir de nada más. Esta lección de cierre no introduce un primitivo nuevo: destila las cuatro anteriores en una disciplina de diseño, un catálogo de olores que delatan que guardas de más, y el reconocimiento honesto de las pocas excepciones donde lo que parece derivado es, en realidad, un hecho que debes registrar.

La regla y su prueba

La regla se opera con una pregunta que aplicas a cada candidato a estado, y que ya usamos en la primera lección con otra forma: ¿puedo calcular este valor a partir de otro estado o de las props, durante el render? Si la respuesta es sí, no lo guardes; derívalo. Solo cuando la respuesta es no —cuando el dato es una verdad primitiva que nada más determina— merece ser estado fuente. Esta prueba del render es más estricta que la intuición, porque descubre como derivados muchos datos que instintivamente guardaríamos: recuentos, totales, banderas de validez, listas filtradas, el elemento seleccionado. El objetivo es que tu conjunto de estado fuente sea el mínimo del que todo lo observable pueda reconstruirse, y ni un dato más.

flowchart TD
Q[tengo un dato candidato a estado] --> C{puedo calcularlo de otro estado o de las props}
C -->|si| D[no lo guardes, derivalo en el render]
C -->|no| H{debe congelarse en el tiempo como un hecho}
H -->|si| F[es fuente, un hecho registrado]
H -->|no| S[es fuente, una verdad primitiva]
style D fill:#a6e3a1,color:#11111b
style F fill:#89b4fa,color:#11111b
style S fill:#89b4fa,color:#11111b

Las señales de que guardas de más

Ciertos patrones delatan, casi sin excepción, un estado que debería ser derivado. Aprender a olerlos convierte la regla en un reflejo. El más elocuente es un useEffect cuya única misión es actualizar un trozo de estado a partir de otro: ese efecto no es lógica, es el síntoma de que dos estados están acoplados y uno debería derivarse del otro. Le sigue de cerca el estado que siempre se escribe junto a otro —dos setters que nunca se llaman por separado suelen ser una fuente y sus derivados mal separados—, y la duplicación pura: la misma entidad guardada en dos sitios, condenada a divergir.

El caso de los booleanos contradictorios merece detenerse, porque conecta con el siguiente track. Tres banderas independientes para un mismo proceso permiten representar estados imposibles —cargando y con error a la vez, o con datos y aún cargando— y cada combinación imposible es un bug esperando a ocurrir. La solución es reducir esas banderas a un único estado fuente del que todas se derivan; llevado al extremo, ese estado único con transiciones explícitas es una máquina de estados, el tema del nivel siguiente.

// Antipatron: banderas sueltas que pueden contradecirse
const [cargando, setCargando] = useState(false);
const [error, setError] = useState(null);
const [datos, setDatos] = useState(null); // cargando y error pueden ser true a la vez

// Fuente minima: un solo estado; las banderas se derivan y no pueden mentir
const [estado, setEstado] = useState({ tipo: "inactivo" });
const cargando = estado.tipo === "cargando";
const hayError = estado.tipo === "error";

El patrón del identificador frente al objeto es igual de recurrente. Guardar el objeto seleccionado lo duplica —ya vive en la colección— y lo congela: si la colección se actualiza, tu copia seleccionada queda vieja. Guardar solo el id como fuente y derivar el objeto de la colección elimina ambos problemas de un plumazo, y es el mismo principio que sostiene la normalización del estado de servidor, donde guardas entidades por id y derivas cada vista de esa única copia.

// Antipatron: guardar el objeto seleccionado, que se duplica y envejece
const [seleccionado, setSeleccionado] = useState(null);

// Fuente minima: guardar el id; el objeto se deriva de la coleccion viva
const [seleccionadoId, setSeleccionadoId] = useState(null);
const seleccionado = items.find((i) => i.id === seleccionadoId) ?? null;

Las excepciones legítimas

La regla es un valor por defecto potente, no un absolutismo, y un ingeniero maduro reconoce sus fronteras. La excepción más importante no es técnica sino conceptual: a veces, lo que parece derivado es en realidad un hecho que debe congelarse en el tiempo. El total de una factura en el momento de la compra no es una derivación de los precios actuales de los productos; es un dato histórico que debe permanecer inmutable aunque esos precios cambien mañana. Calcularlo al vuelo desde los precios vigentes sería, de hecho, un bug: reescribiría el pasado. Aquí el valor es estado fuente pese a su apariencia derivada, porque su verdad quedó fijada en un instante y no debe seguir a sus antiguas entradas.

La otra frontera es de rendimiento, y es más rara de lo que se cree. Cuando una derivación es tan cara que ni la memoización ni el corte por igualdad la hacen viable bajo demanda —un agregado sobre un volumen enorme que se consulta constantemente—, puede justificarse materializar el resultado como una copia denormalizada. Pero es una decisión que se toma con datos del perfilador, no por intuición, y que asume conscientemente la deuda de mantener ese caché coherente. Confundir esta excepción medida con la comodidad de tener el valor a mano es el origen de la mayoría de las duplicaciones que la regla combate.

Agrupar lo relacionado y otras derivaciones cotidianas

Dos correcciones más cierran el catálogo. La primera es agrupar el estado relacionado: cuando varios trozos de estado cambian siempre juntos —las coordenadas de un puntero, los campos de un mismo formulario—, mantenerlos como estados sueltos invita a actualizarlos por separado y a que se desincronicen; reunirlos en un solo objeto de estado convierte esa coherencia en algo estructural. La segunda, ya vista como espejo de props, es derivar en vez de copiar cuando el dato proviene de las props o de la URL.

Precisamente la URL es una de las fuentes más infrautilizadas. El término de búsqueda, la página actual, el filtro activo: si viven en la URL como fuente, el estado de tu componente se deriva de ella —queda compartible, navegable con el botón de atrás y recargable— en lugar de duplicarse en un useState que hay que sincronizar con la barra de direcciones. Lo mismo vale para los formularios, donde el valor de un campo es fuente, pero su validez, sus errores y si está sucio son derivaciones que no deben almacenarse.

// La URL como fuente: el estado de la vista se deriva, no se duplica
const params = new URLSearchParams(location.search);
const busqueda = params.get("q") ?? "";        // fuente: la URL
const pagina = Number(params.get("p") ?? 1);   // fuente: la URL
// nada de esto se copia a useState; cambiarlo es navegar, no hacer setState

// En un formulario, el valor es fuente; validez y errores se derivan
const [valores, setValores] = useState({ email: "" });
const errores = validar(valores);              // derivado, jamas almacenado
const esValido = Object.keys(errores).length === 0; // derivado del derivado

El catálogo completo cabe en una tabla que puedes usar como lista de revisión: a la izquierda, el olor; a la derecha, la derivación que lo disuelve.