Rendimiento: useSelector y suscripciones de grano fino

useMachine es cómodo pero indiscriminado: suscribe el componente al snapshot entero, así que cada transición del actor lo re-renderiza, aunque el dato que ese componente muestra no haya cambiado. En una máquina pequeña da igual. En una que emite eventos a alta frecuencia —el progreso de una descarga, la posición de un cursor, un stream de mensajes—, o en un árbol donde muchos componentes observan el mismo actor, esa suscripción total se convierte en renders desperdiciados que se propagan hacia abajo. El remedio no es memoizar a ciegas: es suscribirse mejor. useSelector proyecta el snapshot a la porción exacta que un componente necesita y solo lo despierta cuando esa porción cambia.

El coste de suscribirse a todo

Cada transición produce un snapshot nuevo, y useMachine fuerza un render por cada snapshot. Si un componente solo pinta state.context.contador pero la máquina también emite eventos de posicionRaton, ese componente se re-renderiza con cada movimiento del ratón para no cambiar nada visible. El problema no es que el render sea caro por sí mismo, sino que se repite sin motivo y arrastra a los hijos. La pregunta correcta no es “¿cómo memoizo este componente?” sino “¿a qué debería estar suscrito de verdad?”.

// Sin selector: se re-renderiza en CADA transicion, aunque solo pinte el contador
const [state] = useMachine(maquina);
return <span>{state.context.contador}</span>;

// Con selector: solo se re-renderiza si cambia el contador
const contador = useSelector(actorRef, (s) => s.context.contador);
return <span>{contador}</span>;

flowchart TD
A[actor emite snapshot] --> B{useMachine}
A --> C{useSelector contador}
B --> D[render siempre]
C --> E{cambio la rebanada}
E -->|si| F[render]
E -->|no| G[nada]

Conviene ver el problema en su forma más aguda: si el componente que se re-renderiza de más tiene hijos, esos hijos también se re-evalúan salvo que estén memoizados, y la onda se propaga por el subárbol. Envolver cada hijo en memo ataca la propagación pero no la fuente —el padre sigue despertando sin necesidad—. Cortar el problema de raíz es no despertar al padre en primer lugar, y eso es exactamente lo que hace una suscripción de grano fino.

useSelector: una rebanada del snapshot

useSelector(actorRef, selector, comparar?) recibe el actor vivo —el tercer elemento de la tupla de useMachine, o uno obtenido con useActorRef— y una función que extrae la porción que te interesa. El hook suscribe el componente solo a esa porción: tras cada snapshot ejecuta el selector y compara el resultado nuevo con el anterior; si son iguales, no re-renderiza. El comparador por defecto es Object.is, que basta para primitivos.

import { useSelector } from "@xstate/react";

// contadorActor viene por props o de un contexto; NO usamos useMachine aqui
export function Contador({ actorRef }: { actorRef: ActorRefFrom<typeof maquina> }) {
  const contador = useSelector(actorRef, (snapshot) => snapshot.context.contador);
  // Este componente solo re-renderiza cuando cambia contador,
  // no cuando cambian otras partes del context o el estado finito.
  return <span>{contador}</span>;
}

La clave es que el selector se ejecuta en cada snapshot, pero el render solo ocurre si su salida cambió. Así trasladas el trabajo del render, que es caro, a una comparación, que es barata. Un selector bien elegido es la diferencia entre un componente que despierta mil veces por segundo y uno que despierta solo cuando su dato se mueve de verdad. Un matiz que se olvida a menudo: useSelector no evita que el selector corra en cada snapshot, solo que el componente se repinte; por eso el selector debe ser barato y sin efectos, un simple proyector que devuelve un valor comparable.

Elegir el comparador

El tercer argumento de useSelector es una función (a, b) => boolean que decide si dos resultados del selector cuentan como iguales. Para una lista donde solo importa la identidad de sus elementos, una comparación superficial evita renders cuando el array se reconstruye con los mismos miembros. Es la misma disciplina que un selector de Redux memoizado: separar “el dato cambió de referencia” de “el dato cambió de valor”.

import { useSelector } from "@xstate/react";

const comparaShallow = (a: string[], b: string[]) =>
  a.length === b.length && a.every((x, i) => x === b[i]);

const nombres = useSelector(
  actorRef,
  (snapshot) => snapshot.context.usuarios.map((u) => u.nombre),
  comparaShallow,
);

El comparador corre en cada snapshot, así que también debe ser barato: una comparación superficial de longitud y elementos es aceptable, pero una comparación profunda recursiva sobre estructuras grandes puede costar más que el render que ahorra. Mide antes de asumir que comparar siempre gana; el objetivo es que el trabajo total baje, no sustituir un coste por otro mayor.

useActorRef y createActorContext: un actor, muchos selectores

Para que useSelector valga la pena, el componente no debe suscribirse también con useMachine —eso reintroduciría el render total—. useActorRef(maquina) arranca el actor y devuelve solo el actorRef, sin suscripción ni render propio; luego cada componente elige su rebanada con useSelector. Para compartir ese actor por un árbol sin prop drilling, createActorContext(maquina) te da un Provider y hooks useSelector y useActorRef ligados a ese contexto.

import { createActorContext } from "@xstate/react";
import { maquina } from "./maquina";

export const AppMaquina = createActorContext(maquina);

// En la raiz: arranca un unico actor para todo el subarbol
// <AppMaquina.Provider>...</AppMaquina.Provider>

export function Badge() {
  // Cada consumidor selecciona su porcion y re-renderiza de forma independiente
  const pendientes = AppMaquina.useSelector((s) => s.context.pendientes);
  return <b>{pendientes}</b>;
}

El patrón que emerge es potente: un solo actor arranca en la raíz, vive una sola vez y es la única fuente de verdad; cada componente del árbol, por lejano que esté, se suscribe a la rebanada que le concierne y se re-renderiza solo por ella. Es lo contrario de levantar el estado a un padre común que, al cambiar, re-renderiza a todos sus descendientes. Aquí no hay padre que re-renderizar: hay un actor observado por muchos ojos independientes.

Todo esto tiene un límite que conviene decir en voz alta: el grano fino no sale gratis en complejidad, y no todo componente lo necesita ni se beneficia de él.