React concurrente : scheduler, render lanes, useTransition, useDeferredValue, useSyncExternalStore

El problema con el render síncrono

Síncrono significa: “yo pinto este componente, termino, paso al siguiente, termino”. Si hay un componente caro (ExpensiveComponent) por delante en el árbol, el usuario notará input lag: el onChange se ejecuta, pero React no llega al setState que pinta el nuevo valor del <input> porque sigue con la cascada previa.

Batching mitiga parte del problema pero no lo resuelve: agrupas diez setCount en uno, sigues sin tener prioridades, y un setSearchQuery sigue siendo capaz de tragarse el setInputValue del campo.

El scheduler: poner prioridades donde React las necesita

Cuando una actualización entra al scheduler, este decide:

if (nextLane === Sync) {
  queueMicrotask(processNextLane);              // inmediata
} else {
  Scheduler.scheduleCallback(callback, processNextLane);
}

   ┌─────────────────────┐
   │     Event loop      │
   └─────────────────────┘
              │
   ┌──────────┴──────────┐
   ▼                     ▼
┌─────────┐         ┌─────────────┐
│  Task   │         │  Microtask  │
│ (macros)│         │ queue       │
└─────────┘         └─────────────┘
   setTimeout, I/O   promises, queueMicrotask

ensureRootIsScheduled(root) se ejecuta cuando un root recibe una actualización:

1. Añade el root a una lista global de roots pendientes.
2. Marca mightHavePendingSyncWork = true para que flushSync lo respete.
3. Encola una microtask (scheduleImmediateTask(processRootScheduleInMicrotask)) si todavía no hay una.
4. Si no estamos en act() (modo test) y el flag enableDeferRootSchedulingToMicrotask está deshabilitado, agenda la tarea de render directamente.

Render lanes: el corazón de la concurrencia

Reemplazan al antiguo concepto de renderExpirationTime. Cada actualización se asigna a un lane, un bit de un bitmask que codifica su prioridad. El bitmask permite operar con varias lanes a la vez (entrelazado, rebase, etc.).

socket.onmessage = (e) => {
  startTransition(() => {
    setMessages(prev => [...prev, e.data]);   // → TransitionLanes (baja prioridad)
  });
};

<button onClick={() => setCount(c => c + 1)}>   // → SyncLane (alta prioridad)

Flujo de procesamiento

1. Collect     →  agrupa updates del último render en sus lanes
2. Process     →  itera lanes de mayor a menor prioridad
                  updates del mismo lane se batchean
3. Commit      →  fase síncrona: aplica al DOM, corre effects
4. Repeat

Conceptos avanzados que el libro menciona sin enterrarse: entanglement (dos lanes que deben procesarse juntas, p. ej. cuando una transición termina en un update síncrono) y rebasing (reordenar updates cuando una transición es interrumpida por algo más urgente).

useTransition y startTransition

useTransition devuelve [isPending, startTransition]. Cualquier actualización envuelta en startTransition se procesa en una transition lane — más baja que SyncLane — y React puede interrumpirla si llega algo urgente.

const ChatApp = () => {
  const [messages, setMessages] = useState([]);
  const [isPending, startTransition] = useTransition();

  useEffect(() => {
    const socket = new WebSocket("wss://your-server.com");
    socket.onmessage = (e) => {
      startTransition(() => {                                // ← baja prioridad
        setMessages(prev => [...prev, e.data]);
      });
    };
    return () => socket.close();
  }, []);

  return (
    <div>
      <MessageList messages={messages} />
      {isPending && <small>Rendering…</small>}
      <MessageInput onSubmit={sendMessage} />
    </div>
  );
};

isPending se actualiza vía setState síncrono inmediatamente después de empezar una transición, así que es seguro leerlo para mostrar feedback.

Tres formas de usarlo

Navegación entre páginas con Suspense

function App() {
  const [page, setPage] = useState("pageOne");
  const [isPending, startTransition] = useTransition();

  const goTo = (p) => startTransition(() => setPage(p));

  return (
    <>
      {isPending && <p>Loading…</p>}
      {page === "pageOne" ? <PageOne /> : <PageTwo />}
    </>
  );
}

Aquí el truco no es “ir más lento” sino atar isPending a Suspense: si la siguiente página suspende (data fetch en servidor), React mantiene isPending=true hasta que los datos llegan y el árbol está listo.

useDeferredValue: stale-while-revalidate puro

useDeferredValue(value) devuelve un valor que retrasa su actualización cuando value cambia. Equivale conceptualmente a useTransition aplicado al valor:

function Search() {
  const [query, setQuery] = useState("");
  const deferredQuery = useDeferredValue(query);   // "se actualiza cuando pueda"

  return (
    <>
      <input value={query} onChange={(e) => setQuery(e.target.value)} />
      <SearchResults query={deferredQuery} />     {/* recibe el valor deferido */}
    </>
  );
}

const SearchResults = memo(({ query }) => { /* ... costoso ... */ });

Comportamiento dinámico

useDeferredValue no impone un delay fijo. Adapta la espera a la capacidad del dispositivo:

• En un Mac M3: la lista puede rerender casi sin pausa.
• En un Android de gama baja: se retrasa lo justo para que el <input> siga respondiendo.
• Si el usuario teclea otra letra mientras la lista está rerenderizando, React interrumpe el rerender de la lista, actualiza el input, y vuelve al rerender.

vs. debounce / throttle

Tearing y useSyncExternalStore

La concurrencia tiene un tradeoff incómodo: si un componente lee un valor mientras se está rerenderizando y ese valor cambia a mitad del render, varios componentes pueden ver valores distintos del mismo estado. Esto es tearing.

let count = 0;
setInterval(() => count++, 1);   // mutación externa al render

const ExpensiveComponent = () => {
  const now = performance.now();
  while (performance.now() - now < 100) { /* bloquear 100ms */ }
  return <>Expensive count is {count}</>;   // lee la variable global
};

Al pintar cinco ExpensiveComponent, React los interrumpe para responder al typing del input. Cuatro podrían leer count = 568, uno count = 570. La UI es internamente inconsistente.

Cómo lo arregla useSyncExternalStore

const store = {
  subscribe(forceSyncRerender) {
    setInterval(() => forceSyncRerender(), 1);
    return () => clearInterval(interval);
  },
  getSnapshot() { return count; },
};

const ExpensiveComponent = () => {
  const consistentCount = useSyncExternalStore(store.subscribe, store.getSnapshot);
  // ... dibuja consistentCount ...
};

Equivale al getDerivedStateFromProps que pedía un valor antes del commit, o al viejo patrón con useEffect + useState, solo que ahora el handshake entre source y React es declarativo y la inconsistencia imposible.

Resumen del capítulo

Próximos pasos

Toda esta base teórica converge en una pregunta práctica: ¿qué framework uso?. Entramos en 09-frameworks.