Los stores en Solid son una primitiva reactiva diseñada para manejar listas y datos complejos como objetos, arrays, maps o sets, optimizando renderizados y actualizaciones sin recrear toda la estructura. Si ya entiendes signals, vas a ver que los stores funcionan parecido, pero con mucha más profundidad.

¿Qué son los proxies de JavaScript y por qué importan en Solid?

Los stores se construyen sobre proxies, así que vale la pena entender de dónde viene ese concepto antes de tocar código.

El término proxy viene de redes y sistemas. Imagina una conexión entre un usuario y un servidor: sin protección, un atacante puede entrar, modificar la conexión o ver información sensible. También existen restricciones por localización que bloquean accesos. Un proxy actúa como intermediario: un túnel que modifica la conexión para asegurarla, redirigirla o aplicarle reglas.

De ahí salen tres piezas que vas a ver una y otra vez:

• Un origen, que es quien inicia la conexión.
• Un destino, que es a dónde quieres llegar.
• Un túnel o proxy, que intercepta y aplica reglas.

¿Qué es un proxy en JavaScript? Es un objeto que envuelve a otro y define trampas (handlers) para interceptar operaciones como leer, escribir o eliminar propiedades, permitiéndote ejecutar lógica personalizada cuando alguien interactúa con él.

En JavaScript, esas reglas se llaman trampas o traps. Son handlers que se disparan cuando el código intenta hacer algo sobre el objeto envuelto.

¿Qué trampas existen en un proxy de JavaScript?

Hay varias trampas útiles que aparecen al trabajar con stores:

• get: se dispara cuando alguien accede a una propiedad del objeto.
• deleteProperty: se activa cuando se intenta eliminar una propiedad.
• apply: se ejecuta cuando se llama a una función envuelta por el proxy.
• has: se dispara cuando se usa el operador in sobre el objeto.

Cada trampa te deja interceptar un pedazo específico de sintaxis de JavaScript y reaccionar a él. Esa es la base de todo lo que viene.

¿Cómo se implementa un store en una librería reactiva propia?

En módulos anteriores construimos signals, effects y memos desde cero. El store es otra primitiva más, pero pensada para datos complejos.

La firma básica se parece a un signal: recibes un valor inicial y devuelves una segregación de lectura y escritura. La diferencia está en que el valor que entregas para lectura no es una función, sino un proxy de JavaScript.

js const [todos, setTodos] = createStore(value)

El value casi siempre es un dato complejo: un objeto, un arreglo, una función, un map o un set.

¿Cómo funciona la trampa get dentro de un store?

Cuando defines la trampa get en el proxy, cualquier acceso a una propiedad activa tu lógica. Por ejemplo, si haces todos[0], internamente el get se dispara y puedes:

1. Detectar el observer actual usando el mismo contexto que usan los effects.
2. Agregar ese effect a la lista de suscriptores del store.
3. Devolver el valor correspondiente al índice o clave solicitada.

Así, si dentro de un effect haces console.log(todos[0]), ese efecto queda automáticamente suscrito a cambios en esa posición. Igualito que con signals, pero a nivel de propiedades.

Lo interesante es que Solid no se queda en el primer nivel. Define proxies recursivamente para cada propiedad interna, sin importar la profundidad. Por eso puedes hacer algo como todos[0].done o acceder a propiedades muy anidadas y la reactividad se sigue disparando con precisión quirúrgica.

¿Cómo se escribe en un store y por qué es tan flexible?

La función de escritura es donde los stores se ponen realmente interesantes. A diferencia de un signal, donde reemplazas el valor completo, aquí puedes modificar valores muy internos sin tocar el resto.

Una implementación mínima del write recibe el índice, la clave y el nuevo valor:

js setTodos(0, 'done', true)

Eso modifica todos[0].done a true y luego ejecuta todos los suscriptores asociados. La estructura interna usa un new Set() para los subscribers, igual que en los signals.

¿En qué se diferencia un store de un signal? Un signal maneja un valor único y lo reemplaza completo. Un store maneja datos complejos con proxies anidados y permite modificar propiedades internas a cualquier nivel sin recrear todo el objeto.

¿Por qué el setter de un store soporta tantas formas de uso?

Si revisas el código fuente de Solid, vas a encontrar la interfaz SetStoreFunction con un montón de overloads. Puedes llamar al setter con uno, dos, tres, cuatro o más argumentos para llegar a niveles cada vez más profundos.

Por ejemplo, con un objeto anidado tipo { details: { prop: value } }, puedes hacer:

js setTodos('details', 'prop', newValue)

Esa cascada de firmas existe porque para Solid es esencial poder modificar cualquier nivel de la estructura. Implementarlo a mano es complejo: por eso esta lección muestra el flujo conceptual y no una réplica completa.

Conceptos y habilidades que se trabajan en la clase

Para que el mapa quede claro, estos son los puntos técnicos que aparecen y dónde se explican:

• Proxies de JavaScript como intermediarios con trampas configurables [01:05].
• Trampas get, deleteProperty, apply y has aplicadas a objetos y funciones [03:30].
• createStore como primitiva reactiva para datos complejos [05:10].
• Suscripción de effects mediante el observer actual dentro del get [06:45].
• Reactividad anidada con proxies recursivos en cada propiedad [07:50].
• Setter dinámico con múltiples overloads para modificar propiedades profundas [09:20].
• SetStoreFunction y su cascada de firmas en el código fuente de Solid [10:40].

Con esto en la cabeza, el siguiente paso es llevar los stores a la aplicación real de Todos. ¿Ya tenías idea de que detrás de un store había tantos proxies trabajando? Cuéntame en los comentarios cómo te imaginas usarlos en tu próximo proyecto.