Cómo funcionan los stores en Solid JS
Contenido del curso
Cesar Payro
Enrique Giraldo Puentes
Kenneth Angulo L
Kevin J. Zea Alvarado
me perdi completamente en este clase.. al no saber que es todo estos de los proxys aplicado a los valores reactivos.. talvez porque el concepto de 'store' (de otros frameworks) me hace pensar en un store centralizado qeu comparte valores a todo el DOM para no pasar datos 'nested' como props
Aquí tienes una explicación clara de qué son los Proxies en Solid y cómo te permiten evitar el "prop drilling" (pasar datos a componentes muy anidados) sin un store global tradicional:
1. ¿Qué es un Proxy en Reactividad? 🧐
Un Proxy es un objeto de JavaScript que envuelve a otro objeto o valor. Su función principal es interceptar operaciones fundamentales (como leer, escribir o eliminar propiedades) dirigidas al objeto original.
En el contexto de SolidJS: Cuando creas un estado reactivo complejo, como una lista o un objeto anidado usando createStore (que es el "store" de Solid, pero no es un store global en el sentido tradicional), Solid envuelve ese objeto en un Proxy.
El Poder del "Enganche" (Hooking):
Lectura: Cuando un componente lee una propiedad de ese objeto Proxy (ej: userStore.profile.name), el Proxy lo detecta y "registra" a ese componente como un "observador" de esa propiedad exacta.
Escritura: Cuando escribes en una propiedad (ej: setUserStore('profile', 'name', 'NuevoNombre')), el Proxy lo detecta e inmediatamente le dice a solo los componentes que estaban "enganchados" a esa propiedad que se actualicen.
En esencia, el Proxy crea el vínculo entre el dato y el DOM sin que tú tengas que hacerlo manualmente.
2. Los Dos Tipos de Reactividad en Solid
Solid usa dos tipos de valores reactivos, y solo uno usa el concepto de Proxy:
Tipo de Reactividad Función de Solid Uso Típico ¿Usa Proxy?
Granular/Atómico (Signals) createSignal Valores primitivos (números, booleanos, strings). ❌ No.
Estructurado (Stores) createStore Objetos o arrays complejos y anidados. ✅ Sí.
Exportar a Hojas de cálculo
Conclusión: Cuando se habla de Proxies en Solid, generalmente se refiere a cómo maneja los stores (objetos complejos) creados con createStore.
3. ¿Cómo Evita el Prop Drilling (sin un Store Global)?
Aquí es donde Solid brilla y donde el concepto de Proxy ayuda a resolver tu confusión sobre el store centralizado.
Tu idea de un store que evita pasar props anidadas es correcta, pero Solid lo logra de una manera más descentralizada y eficiente:
La Magia de Pasar la Referencia del Proxy
Cuando pasas un valor reactivo de un componente padre a un hijo, no estás pasando el valor actual, sino la referencia al objeto Proxy.
Componente Padre: Crea el store o signal.
Paso de Prop: El padre pasa la función de lectura de un signal (count()) o la referencia del store (userStore) al hijo.
Componente Nieto (Anidado): El nieto, que está muy anidado, lee el valor (ej: props.userStore.profile.name).
Activación del Proxy: Al leerlo, el Proxy detecta la lectura y sabe que este nieto es un observador.
Actualización Dirigida: Si el padre cambia el nombre, el Proxy notifica directamente al nieto (y solo al nieto) para que se actualice.
La ventaja es:
Se evita el Prop Drilling: El valor se puede leer desde cualquier nivel anidado (simulando un store global).
Se evita la Re-renderización Innecesaria: A diferencia de otros frameworks, los componentes intermedios (el hijo, en este caso) no tienen que re-renderizarse ni re-ejecutarse, porque el cambio va directamente del Proxy al componente final que lo usa.
El Proxy permite que el componente anidado se "enganche" al dato sin necesidad de un context o store central si no lo deseas.
¿Cuándo debo elegir stores sobre los signals?
Debes elegir stores en el momento en que tus datos comiencen a tener múltiples niveles de profundidad o cuando necesites mutar propiedades específicas sin afectar el resto del conjunto.
Una regla práctica muy sencilla es:
createSignal para contadores, booleanos de estado (como abrir o cerrar un modal) o strings simples.createStore para listas de tareas, carritos de compras, perfiles de usuario con múltiples campos o cualquier estructura donde uses arreglos [] u objetos {}.Si te encuentras haciendo copias profundas de un objeto (usando el spread operator ...) dentro de un signal solo para actualizar un valor pequeño, es la señal definitiva de que necesitas migrar ese estado a un store para mejorar la ergonomía y el rendimiento.
Al principio, me pareció un concepto un poco difícil de entender, así que investigué. Les comparto un resumen de cómo lo entendí, por si les sirve.
Un Store en SolidJS es distinto a un Store en otras librerías como React (con Redux), que es la única librería de JavaScript que he estudiado y de la que había escuchado el término.
En términos simples, el Store en Solid es para manejar mejor la reactividad cuando se trabaja con objetos complejos (arrays, objetos literales, etc.).
Es decir, si tenemos el objeto user = { name: "John", age: 20 } y un elemento accede a user.name y otro a user.age, lo que permite el Proxy en el Store es que cuando cambie el valor de user.age, no se actualicen ambos elementos sino solo el que hace uso de la edad.
En otro ejemplo más extremo: si se tiene una lista de 10,000 items, con createSignal al cambiar un elemento, se recalcula todo el array dependiente; con createStore, si se cambia un solo item, solo se reactiva lo que depende de ese índice.
Esto hace que SolidJS sea muy eficiente.
Por lo tanto, los Signals son más adecuados cuando el estado es pequeño o tiene un valor primitivo.