Stores de SolidJS para datos complejos

Contenido del curso

No sé dónde empezar

Introducción a SolidJS

Reactividad a profundidad

Renderizado en Solid

Reactividad en Listas

Componentes

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:008:39

Stores de SolidJS para datos complejos

Curso de SolidJS

Clase 20 de 27

Clase 20 / 27

Recursos

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.

Resumen

¿Qué son los stores en SolidJS y por qué usarlos?

¿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?

¿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);

¿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?

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?

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.

Introducción a SolidJS

SolidJS vs React: reactividad granular explicada

Python para Principiantes: Fundamentos y Aplicaciones Básicas

Signals en SolidJS: crea datos reactivos

createEffect y side effects en SolidJS

Signals derivados vs createMemo en Solid

Reactividad a profundidad

Qué es la reactividad en Solid

Creación de una Librería Reactiva MiniSolid desde Cero

Implementación de Signals en Librería Reactiva Solid

Cómo createEffect conecta signals y efectos

Señales derivadas sin nuevas primitivas

createMemo para evitar renderizados innecesarios

Cómo Solid convierte JSX al DOM real

Renderizado en Solid

Configurando SolidJS con Tailwind para Todo App

Dark mode en SolidJS con signals

Renderizado Condicional en Solid: Técnicas y Optimización

Renderizado de listas reactivas con For en Solid

Manejo de Eventos en Elementos HTML con SolidJS

Reactividad en Listas

Optimización de Renderizado y Reactividad en Listas con SolidJS

Cómo funcionan los stores en Solid JS

Stores de SolidJS para datos complejos

Función produce para mutar stores en Solid

Componentes

Qué son los componentes en Solid

Comunicación padre-hijo con props en SolidJS

Eventos personalizados entre componentes React

Persistencia con localStorage y useEffect

Deploy de app Solid en Netlify

Solid y el futuro del desarrollo web

Stores de SolidJS para datos complejos