Anatomía de un signal

Toda la reactividad de SolidJS se levanta sobre un único primitivo: el signal. Un createSignal no es una variable mágica ni un objeto observable al estilo clásico; es un par de funciones —una para leer y otra para escribir— y ese detalle en apariencia menor, que leer sea invocar una función, es justo lo que hace posible el rastreo de dependencias de grano fino. Antes de construir moléculas, disequemos el átomo.

El par [getter, setter]

createSignal recibe un valor inicial y devuelve una tupla de exactamente dos elementos: un getter para leer el valor actual y un setter para reemplazarlo. La convención universal es desestructurar esa tupla con un nombre y ese mismo nombre prefijado con set:

import { createSignal } from "solid-js";

const [count, setCount] = createSignal(0);

count();      // 0  -> leer es LLAMAR a la funcion
setCount(5);  // escribir un valor nuevo
count();      // 5

Que sea una tupla y no un objeto { get, set } es deliberado: te obliga a nombrar ambas mitades en el punto de creación y hace visible, de un vistazo, quién puede leer y quién puede escribir. Puedes entregar solo el getter a un componente hijo y guardarte el setter, logrando un valor de solo lectura sin ceremonia alguna.

const [count, setCount] = createSignal(0);
const soloLectura = count;   // reparte lecturas y nada mas
// setCount queda encapsulado: nadie de fuera puede mutar el estado

El getter es una función, no un valor

Aquí está la decisión de diseño que distingue a Solid de casi todo lo demás. En otros sistemas, un estado reactivo es una propiedad: lees state.count y una capa de proxies intercepta el acceso. Solid renuncia al proxy para el signal y te da una función explícita: escribes count(), con paréntesis. ¿Por qué molestarse?

Porque una lectura debe poder hacer dos cosas a la vez: devolver el valor y registrar quién lo está leyendo. Una función es el lugar natural para ese doble trabajo. Cuando llamas a count(), el getter no solo retorna el número: consulta si hay una computación reactiva activa —un efecto, un memo, el propio JSX— y, si la hay, la inscribe como observadora. Un acceso a propiedad plano no tendría dónde colgar ese comportamiento sin recurrir a proxies.

const [count, setCount] = createSignal(0);

console.log(count);    // [Function]  <- la funcion en si, casi nunca lo que quieres
console.log(count());  // 0           <- el valor, invocando el getter

Leer es suscribirse

Esta es la frase que hay que grabar a fuego. En Solid, el acto de llamar a count() dentro de un ámbito reactivo no es una lectura pasiva: es declarar una dependencia. El signal guarda internamente el conjunto de sus observadores; la computación activa guarda la lista de sus fuentes. Leer teje ese enlace bidireccional; escribir lo recorre para notificar.

flowchart LR
A[count llamado dentro de un efecto] --> B[el signal registra al efecto como observer]
B --> C[el efecto guarda al signal como source]
D[setCount con un valor nuevo] --> E[el signal recorre sus observers]
E --> F[el efecto se vuelve a ejecutar]

La consecuencia es que no hay lista de dependencias que declarar. No existe un array como el de useEffect; el sistema descubre las dependencias ejecutando tu código y anotando qué getters se invocaron. Si esta vez leíste count() y name(), dependes de ambos; si un if hace que la próxima vez solo leas count(), la suscripción a name se descarta automáticamente. El grafo es dinámico y siempre exacto.

Fuera de un ámbito reactivo —en el cuerpo de una función normal, en un manejador de evento— llamar a count() simplemente devuelve el valor sin suscribir a nadie. La misma función se comporta como lectura reactiva o como lectura inerte según dónde la invoques. Esa dualidad, que exploraremos en la próxima lección, es la fuente tanto del poder de Solid como de sus confusiones más típicas.