Estado local de UI

La primera clase de la taxonomía es la más humilde y la más frecuente: el estado que pertenece a un único componente, que ninguna otra parte de la app necesita ver, y que desaparece cuando la vista se desmonta. Un acordeón abierto, un botón en hover, el foco de un campo. Reconocerlo importa tanto como reconocer a los demás, porque el error de principiante no es olvidarlo: es ascenderlo a una categoría superior que no le corresponde.

La firma del estado local: ámbito y tiempo de vida

Un estado es local cuando cumple dos condiciones a la vez: su ámbito es un solo componente (nadie más lo lee) y su tiempo de vida coincide con el del componente (se crea al montar, se destruye al desmontar). No lo define su contenido —un booleano puede ser local o global—; lo definen esas dos coordenadas.

function Acordeon({ titulo, children }: Props) {
  const [abierto, setAbierto] = useState(false); // nace aqui, muere aqui
  return (
    <section>
      <button onClick={() => setAbierto((v) => !v)}>{titulo}</button>
      {abierto && <div>{children}</div>}
    </section>
  );
}

El booleano abierto no significa nada fuera de este Acordeon. Dos acordeones en la misma página tienen dos estados independientes, sin coordinación ni conflicto. Ese aislamiento no es un detalle de implementación: es la propiedad que hace al estado local trivial de razonar. No hay carreras, no hay obsolescencia, no hay que invalidarlo — porque nadie más lo comparte.

flowchart LR
M[montar componente] --> I[inicializar estado local]
I --> U[interaccion del usuario]
U --> R[re-render con el nuevo valor]
R --> U
U --> D[desmontar vista]
D --> G[el estado se destruye]
style I fill:#89b4fa,color:#11111b
style R fill:#a6e3a1,color:#11111b
style G fill:#f38ba8,color:#11111b

El diagrama captura la firma: el estado no sobrevive al ciclo de vida de la vista. Si necesitas que persista más allá —recordar el acordeón abierto tras recargar— ya no es estado local; es persistencia (Nivel 36) o estado de URL (lección 4 de este nivel). Ese es el primer corte de la taxonomía: no preguntas qué guarda el dato, sino cuánto debe vivir.

No todo estado local provoca un render

useState es el caso por defecto, pero el ámbito local admite tres herramientas con semánticas distintas:

const [valor, setValor] = useState(0);          // cambia -> re-render
const [estado, dispatch] = useReducer(fn, init); // transiciones nombradas
const idInterval = useRef<number | null>(null);  // muta SIN re-render

La distinción crítica es entre useState y useRef. Ambos guardan un valor que sobrevive entre renders, pero useState agenda un render cuando cambia y useRef no. El estado local que la UI muestra (abierto, texto del campo) va en useState; el estado local que solo necesitas recordar entre renders sin pintarlo (un temporizador, la posición previa del scroll, un nodo del DOM) va en useRef. Confundirlos produce los dos bugs clásicos: renders infinitos por escribir en useState donde bastaba una ref, o UI congelada por mutar una ref donde se esperaba un render.

useReducer no cambia el ámbito —sigue siendo local— sino la disciplina: cuando las transiciones del componente son varias y se relacionan (un asistente por pasos, un campo con validación y estados de envío), un reducer local convierte mutaciones dispersas en transiciones nombradas y testeables. Es la máquina de estados (Niveles 9-16) en miniatura, sin salir del componente.

type Accion = { tipo: 'siguiente' } | { tipo: 'atras' } | { tipo: 'reset' };

function pasos(estado: number, accion: Accion): number {
  switch (accion.tipo) {
    case 'siguiente': return Math.min(estado + 1, 3);
    case 'atras':     return Math.max(estado - 1, 0);
    case 'reset':     return 0;
  }
}
// el estado sigue siendo local; solo cambia como se muta: por acciones
const [paso, dispatch] = useReducer(pasos, 0);

No todo lo que parece estado lo es. Si un valor se puede calcular a partir de otro estado o de las props en cada render, no lo guardes: derívalo. Duplicarlo en un useState crea una segunda fuente de la verdad que hay que sincronizar a mano y que tarde o temprano discrepará.

// ANTI-PATRON: estado derivado duplicado, hay que recordar actualizar el total
const [items, setItems] = useState<Item[]>([]);
const [total, setTotal] = useState(0);

// CORRECTO: derivar en el render, sin estado extra ni sincronizacion
const [items, setItems] = useState<Item[]>([]);
const total = items.length; // siempre consistente por construccion

El mismo concepto fuera de React

El estado local no es una idea de React; es una idea del ámbito léxico. En los modelos de signals de 2026 el patrón es idéntico, solo cambia la sintaxis: un valor reactivo declarado dentro del componente o del setup.

// Solid: el signal vive en el ambito de la funcion componente
function Acordeon() {
  const [abierto, setAbierto] = createSignal(false);
  return <button onClick={() => setAbierto((v) => !v)}>Alternar</button>;
}

En Svelte 5, let abierto = $state(false) dentro de un componente; en Vue, const abierto = ref(false) en el setup. Todos expresan lo mismo: un dato cuyo ámbito es el componente y cuyo tiempo de vida es su instancia. La lección transversal —y el motivo de toda esta taxonomía— es que la clase de estado precede a la librería. Primero decides que algo es local; después eliges cómo lo expresas.

Que el modelo sea de grano fino (signals, con reactividad quirúrgica) o de re-render por componente (React) cambia el rendimiento y la ergonomía, pero no la clasificación: un signal declarado dentro de un componente sigue siendo estado local, con el mismo ámbito y el mismo tiempo de vida que un useState. La taxonomía es anterior e independiente del motor de reactividad — por eso viaja intacta entre frameworks.

El pecado original: elevar antes de tiempo