No hay lifecycle de update

En los frameworks con re-render existe un hueco natural llamado “actualización”: el momento entre un render y el siguiente, donde enganchas componentDidUpdate o un useEffect con dependencias para reaccionar a lo que cambió. En Solid ese hueco no existe, porque no existe el siguiente render: el cuerpo corre una vez y nunca vuelve. Y sin embargo tu interfaz reacciona a los cambios mejor que nunca. La clave es que reaccionar no es un momento del ciclo de vida que interceptas, sino una relación que declaras: un efecto que rastrea lo que lee y se re-ejecuta solo cuando eso cambia.

El hueco que no existe

En React, el modelo mental de “reaccionar” está ligado al render: el componente se vuelve a ejecutar, y hooks como componentDidUpdate o useEffect(fn, [dep]) te dan un lugar donde correr después de ese nuevo render. La pregunta que te haces es temporal: “¿qué hago cuando el componente se actualiza?”.

Solid borra esa pregunta. El cuerpo del componente es una factoría que corre una vez, construye el grafo reactivo y termina. No hay un segundo pase, ningún “el componente se actualizó”, ningún array de dependencias que comparar entre renders. Buscar un onUpdate en Solid es buscar un objeto que el modelo no contiene.

Lo que sí hay es reactividad de grano fino. En vez de un hook que corre tras cada render, declaras un efecto que se suscribe exactamente a los signals que lee y se re-ejecuta solo cuando alguno cambia.

import { createEffect } from "solid-js";

function Titulo(props: { nombre: string }) {
  createEffect(() => {
    document.title = `Hola, ${props.nombre}`;   // corre al montar y cuando props.nombre cambia
  });
  return <h1>{props.nombre}</h1>;
}

Ese efecto no necesita saber “el componente se actualizó”. Sabe algo más preciso: props.nombre cambió. No reacciona a un render global, reacciona a un dato concreto.

flowchart TD
subgraph React
  A[cambia el estado] --> B[re-render del componente]
  B --> C[componentDidUpdate corre despues]
end
subgraph Solid
  D[cambia un signal] --> E[solo se re-ejecuta el efecto suscrito]
end
style B fill:#f38ba8,color:#11111b
style E fill:#a6e3a1,color:#11111b

De componentDidUpdate a un efecto

La traducción es directa: donde en React pondrías la lógica de actualización en un hook que observa una dependencia, en Solid pones un efecto que lee esa dependencia. El acto de leerla es lo que crea la suscripción; no hay que declararla en un array aparte.

// React: la dependencia se declara en un array, un lint la vigila
useEffect(() => {
  sincronizar(userId);
}, [userId]);

// Solid: la dependencia se descubre leyendola dentro del efecto
createEffect(() => {
  sincronizar(props.userId);
});

Esto elimina de raíz una familia entera de bugs. No hay dependencias omitidas ni de más, porque no se declaran: se rastrean. No hay closures obsoletas por un array desactualizado, porque el efecto siempre lee el valor vigente. La correspondencia entre “de qué depende” y “qué observa” es automática, no una lista que mantener sincronizada con la lógica.

Cuando necesitas comparar el valor nuevo con el anterior —algo que en React harías guardando un ref con el valor previo— Solid te lo da integrado: el efecto puede recibir su propio retorno anterior.

createEffect((anterior) => {
  const actual = props.pagina;
  if (anterior !== undefined && actual !== anterior) {
    registrarNavegacion(anterior, actual);   // solo cuando de verdad cambio
  }
  return actual;                             // sera el `anterior` del proximo run
}, undefined);

on con defer: reaccionar solo a los cambios

Queda un matiz. Un createEffect corre también en el montaje, no solo en los cambios posteriores; su primera ejecución es parte del arranque. A veces eso es justo lo que no quieres: la semántica exacta de componentDidUpdate es “corre en las actualizaciones, pero no en el montaje inicial”.

Para eso Solid ofrece on, un ayudante que hace explícitas las dependencias y acepta la opción defer. Con { defer: true } el efecto salta su primera ejecución y solo corre a partir del siguiente cambio: la reproducción precisa del hook de actualización.

import { createEffect, on } from "solid-js";

function Filtro(props: { consulta: string }) {
  createEffect(
    on(
      () => props.consulta,
      (consulta, anterior) => {
        // NO corre al montar; solo cuando props.consulta cambia
        buscar(consulta, { desde: anterior });
      },
      { defer: true }
    )
  );
  return <div>...</div>;
}

on invierte la ergonomía por defecto: en vez de descubrir dependencias leyéndolas en cualquier punto del cuerpo, las enumeras en el primer argumento y el cuerpo del segundo queda sin rastreo, de modo que lo que leas dentro no crea suscripciones nuevas. Es la herramienta para cuando quieres control quirúrgico sobre qué dispara el efecto y si el primer run cuenta o no.

De los hooks de ciclo de vida a las primitivas reactivas, el diccionario de traducción es corto: