Contenido del curso
Reactividad a profundidad
- 6

Qué es la reactividad en Solid
05:15 min - 7

Creación de una Librería Reactiva MiniSolid desde Cero
06:46 min - 8

Implementación de Signals en Librería Reactiva Solid
07:01 min - 9

Cómo createEffect conecta signals y efectos
08:50 min - 10

Señales derivadas sin nuevas primitivas
04:40 min - 11

createMemo para evitar renderizados innecesarios
07:26 min - 12

Cómo Solid convierte JSX al DOM real
03:53 min
Renderizado en Solid
Reactividad en Listas
Componentes
Stores de SolidJS para datos complejos
Resumen
Trabajar con listas, objetos o estructuras anidadas en SolidJS puede volverse incómodo si solo usas signals. Aquí entran los stores de SolidJS, una primitiva especial pensada para mejorar la reactividad granular y la ergonomía cuando manejas datos complejos como arrays, objetos, maps o sets.
¿Qué son los stores en SolidJS y por qué usarlos?
Los stores son una primitiva reactiva diseñada para datos complejos. A diferencia de un signal, no devuelven una función, sino un proxy que envuelve tu objeto original y expone trampas que detectan cambios en propiedades específicas.
¿Qué es un store en SolidJS? Es una primitiva reactiva basada en proxies que te permite leer y modificar propiedades específicas de objetos o arrays sin reemplazar toda la estructura.
Por eso se importan desde un paquete distinto al resto de primitivas, mediante solid-js/store. Esa separación marca que estás entrando a un terreno especial dentro del sistema reactivo [01:00].
js import { createStore } from "solid-js/store";
const [todos, setTodos] = createStore([ { text: "Aprender SolidJS", completed: false } ]);
¿En qué cambia el acceso a los datos?
Cuando migras de un signal a un store, el valor deja de ser una función. Si antes escribías todos().map(...), ahora simplemente usas todos.map(...). Lo mismo pasa con propiedades anidadas: todo.completed ya es un valor directo, no una invocación.
Esto rompe temporalmente tu código en todos los lugares donde ejecutabas la lista o sus propiedades como funciones. La buena noticia es que el editor te marca esos puntos rápidamente y la limpieza es mecánica.
¿Cómo modificar un store con setTodos en SolidJS?
El setter de un store no reemplaza el valor completo: te deja apuntar a una ruta específica dentro de la estructura. Esa es la clave de su eficiencia.
Para cambiar el estado completed de un elemento concreto al hacer clic en un checkbox, le pasas el índice y la propiedad que quieres tocar:
js setTodos(index, "completed", c => !c);
Lo mismo aplica cuando editas el texto de un elemento en un evento onBlur. Apuntas al índice, indicas la propiedad text y entregas el nuevo valor desde textContent. No tocas el resto de la lista.
¿Cómo cambio una propiedad de un objeto dentro de un array reactivo? Llama al setter con la ruta exacta:
setTodos(index, "propiedad", nuevoValor). Solid actualiza solo esa parte del proxy.
¿Cómo agregar un elemento nuevo a la lista?
Para insertar un todo al final, usas todos.length como índice de destino. Eso equivale a la siguiente posición disponible:
js setTodos(todos.length, { text: newItem, completed: false });
Ya no necesitas crear signals individuales por cada elemento ni devolver funciones para mutar sus propiedades. Insertas un objeto plano y el store se encarga del resto [05:30].
¿Cómo eliminar un elemento sin reemplazar toda la lista?
El setter también acepta una función que recibe el array actual como argumento. Dentro puedes aplicar métodos nativos de JavaScript como filter para devolver una versión sin el elemento que quieres quitar:
js setTodos(prev => prev.filter((_, i) => i !== index));
Esta sintaxis es familiar si vienes de signals, pero ahora actúa sobre el array real que vive dentro del proxy.
¿Por qué los stores ahorran memoria y procesamiento?
Cuando reemplazas toda la lista en cada cambio, Solid necesita aplicar optimizaciones internas en su componente <For>, como memos que comparan elementos para evitar volver a renderizarlos. Eso consume CPU y memoria.
Con stores, el proxy notifica únicamente la propiedad o el índice que cambió. El resultado es directo y se nota en aplicaciones con listas grandes:
- Menos trabajo de reconciliación interna en
<For>. - Cero clones innecesarios del array completo.
- Reactividad granular hasta el nivel de propiedad anidada.
- Modelo mental más cercano a mutar objetos en JavaScript plano.
Después de migrar el ejemplo de todos, agregar y eliminar elementos se sigue viendo igual en pantalla, pero por debajo estás moviendo mucho menos JavaScript.
¿Cuándo conviene un store y cuándo un signal?
Un signal sigue siendo ideal para valores primitivos: un contador, un texto de input, un boolean. El costo de envolverlo en un proxy no se justifica.
Los stores brillan cuando manejas:
- Arrays de objetos como listas de tareas, productos o usuarios.
- Objetos con varias propiedades que cambian de forma independiente.
- Estructuras tipo map o set donde necesitas reactividad por clave.
- Estado anidado donde solo unas ramas cambian a la vez.
La contrapartida es que debes aprender la sintaxis del setter: rutas por índice o clave, funciones que reciben el valor previo y combinaciones de ambas. Ese es el peaje a cambio de la ergonomía y el rendimiento.
Si ya conoces JavaScript moderno, la curva es corta y el código termina pareciéndose más a una mutación normal que a una gimnasia reactiva. ¿Cómo estás manejando hoy tus listas y objetos en Solid? Cuéntame en los comentarios qué parte del setter te resulta más confusa.