onMount y la disposición automática

Solid no tiene un onUnmount, y no es un olvido: es una consecuencia elegante del árbol de ownership. El montaje y el desmontaje no son dos hooks simétricos que debas emparejar, sino dos caras del mismo owner. onMount cubre la entrada —código que corre una vez cuando el DOM ya existe— y onCleanup cubre la salida, disparado automáticamente cuando el owner se dispone. Entender qué es realmente onMount por dentro, y cómo Solid desmonta componentes sin que tú lo pidas, completa el modelo del ciclo de vida.

onMount es un efecto que no rastrea nada

Conceptualmente, onMount no es una primitiva nueva: es azúcar sobre un efecto que no lee ningún signal.

// idea de la implementacion de onMount
import { createEffect, untrack } from "solid-js";

function onMount(fn) {
  createEffect(() => untrack(fn));   // sin lecturas rastreadas: corre una vez
}

La lógica es limpia. Un createEffect corre después del render y se re-ejecuta cuando cambia alguna de sus dependencias. Si envuelves su cuerpo en untrack, no se suscribe a nada; y si no se suscribe a nada, no hay ningún cambio que pueda dispararlo de nuevo. Resultado: corre exactamente una vez, en la fase de efectos, con el DOM ya construido. Por eso onMount es el lugar canónico para lo que necesita el DOM presente: medir un nodo, dar foco a un campo, inicializar una librería que espera un elemento real.

import { onMount, onCleanup } from "solid-js";

function Mapa() {
  let el;                             // ref al contenedor
  onMount(() => {
    const mapa = crearMapa(el);       // el nodo ya existe en el DOM
    onCleanup(() => mapa.destruir()); // salida emparejada con la entrada
  });
  return <div ref={el} />;
}

Cuándo corre, y por qué no en el servidor

onMount corre después del render inicial y de los createRenderEffect que el compilador usa para poblar el DOM, de modo que cuando entra, las refs ya apuntan a nodos reales. Y corre solo en el cliente: durante el renderizado en servidor, Solid no ejecuta la fase de efectos —el HTML se genera de forma síncrona sin ellos—, así que ningún onMount se dispara en el servidor. Esa es la razón de fondo por la que onMount es el refugio seguro para código que toca window, document o cualquier API del navegador.

Como onMount no rastrea, no reacciona a cambios de props. Si necesitas reaccionar cuando una prop cambie, ese es el trabajo de createEffect, no de onMount. Confundirlos —esperar que onMount se repita— es un error clásico de quien llega buscando el equivalente de un useEffect con array de dependencias vacío.

Medir y tocar el DOM ya construido

El uso estrella de onMount es leer o manipular el DOM real: medir tamaños, posicionar algo respecto a un nodo, arrancar una animación de entrada o conectar una librería imperativa. Todo eso exige que el elemento exista, y onMount es el primer punto del ciclo donde eso está garantizado en el cliente.

import { onMount, createSignal } from "solid-js";

function Medible() {
  let caja;
  const [alto, setAlto] = createSignal(0);

  onMount(() => {
    setAlto(caja.getBoundingClientRect().height); // el nodo ya esta pintado
  });

  return <div ref={caja}>alto medido: {alto()}px</div>;
}

Si intentaras esa medición en el cuerpo del componente, caja aún sería undefined: el cuerpo corre durante la creación, antes de que el JSX se convierta en nodos y se inserte en el documento. El cuerpo cablea; onMount actúa sobre lo ya cableado y pintado.

La disposición automática de componentes

Cada vez que se monta un componente, su cuerpo corre dentro de un owner. Ese owner cuelga del árbol que vimos en la primera lección, y su destino está atado al del subárbol del DOM que produce. Cuando el componente sale de la interfaz —porque un Show conmutó, un For perdió un elemento, un Switch cambió de caso o un Dynamic reemplazó el componente—, Solid dispone ese owner: recorre su subárbol y ejecuta todas las limpiezas de abajo arriba.

flowchart TD
A[montar componente] --> B[correr cuerpo una vez]
B --> C[render effects pueblan el DOM]
C --> D[onMount corre una vez]
D --> E[updates de grano fino]
E --> F[el control de flujo lo quita]
F --> G[disponer el owner]
G --> H[correr todos los onCleanup]
style D fill:#a6e3a1,color:#11111b
style G fill:#f9e2af,color:#11111b
style H fill:#f38ba8,color:#11111b

Esto es lo que elimina la necesidad de un onUnmount. No hay un evento de desmontaje al que suscribirse porque el desmontaje no es un evento del componente: es la disposición de su owner, y ya tienes onCleanup para engancharte a ella. Los componentes de control de flujo crean owners anidados para cada rama y los disponen al cambiar; la raíz de todo, creada por render, dispone el árbol entero cuando llamas a la función que render devuelve.

Un ejemplo hace tangible la cascada. Cada rama de un Show es un subárbol de owners que nace y muere con la condición:

import { Show, onCleanup } from "solid-js";

function Pestana(props) {
  return (
    <Show when={props.abierta()}>
      {(() => {
        const canal = suscribir(props.id);
        onCleanup(() => canal.cerrar()); // corre al cerrar la pestana
        return <Panel canal={canal} />;
      })()}
    </Show>
  );
}

Cuando abierta pasa a falso, Solid dispone por completo el owner de esa rama: el onCleanup cierra el canal y cualquier efecto interno se desmonta, sin que exista ningún onUnmount de por medio. Volver a abrirla no reanuda nada: crea un owner nuevo desde cero, con su propio ciclo de vida.