No hay lifecycle de update

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.

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 vigilauseEffect(() => {  sincronizar(userId);}, [userId]);// Solid: la dependencia se descubre leyendola dentro del efectocreateEffect(() => {  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: