Context + store: estado compartido reactivo de subárbol

Aquí convergen los dos hilos del nivel. El contexto sabe llevar un valor a un subárbol; el store sabe ser estado reactivo de grano fino. Unirlos produce el patrón más importante de la gestión de estado en Solid: un Provider que crea un store por dentro, expone una tupla de estado y acciones, y la reparte por el árbol. Es el equivalente idiomático —y más simple— de lo que en otros ecosistemas se monta con librerías enteras: tema, autenticación, carrito, cualquier estado que un subárbol comparte, resuelto con dos primitivos que ya conoces.

El patrón canónico

La estructura es siempre la misma y conviene memorizarla como una plantilla. Un componente Provider crea el store, define las acciones que lo mutan, ensambla la tupla y la pasa como value. Un hook useX da acceso validado. El objeto de contexto se queda privado al módulo. Es la contrapartida con createStore del patrón factory del nivel anterior: allí el store se empaquetaba con getters; aquí exponemos la tupla [estado, acciones] del proxy.

import { createContext, useContext, type ParentComponent } from "solid-js";
import { createStore, type Store } from "solid-js/store";

interface Linea { id: string; nombre: string; precio: number; cantidad: number }
interface EstadoCarrito { lineas: Linea[] }

type CarritoValor = [
  Store<EstadoCarrito>,
  {
    agregar: (l: Linea) => void;
    quitar: (id: string) => void;
    vaciar: () => void;
  },
];

const CarritoContext = createContext<CarritoValor>();

El tipo ya lo dominamos de la lección anterior: estado de solo lectura para el consumidor, mutación exclusiva por acciones. Ahora el Provider que lo puebla.

El Provider que crea el store

export const CarritoProvider: ParentComponent = (props) => {
  const [estado, setEstado] = createStore<EstadoCarrito>({ lineas: [] });

  const acciones = {
    agregar(l: Linea) {
      const i = estado.lineas.findIndex((x) => x.id === l.id);
      if (i >= 0) setEstado("lineas", i, "cantidad", (c) => c + l.cantidad);
      else setEstado("lineas", (ls) => [...ls, l]);
    },
    quitar(id: string) {
      setEstado("lineas", (ls) => ls.filter((x) => x.id !== id));
    },
    vaciar() {
      setEstado("lineas", []);
    },
  };

  return (
    <CarritoContext.Provider value={[estado, acciones]}>
      {props.children}
    </CarritoContext.Provider>
  );
};

export function useCarrito() {
  const ctx = useContext(CarritoContext);
  if (!ctx) throw new Error("useCarrito requiere un CarritoProvider");
  return ctx;
}

Tres detalles cargan todo el peso. createStore vive dentro del Provider, así que su ciclo de vida queda atado al owner de ese componente. Las acciones cierran sobre setEstado: el consumidor nunca ve el setter, solo verbos de dominio —agregar, quitar, vaciar— que expresan intención, no mecánica. Y el value es una referencia estable —la tupla— cuya reactividad no está en su identidad sino en el store que contiene: recuerda que el contexto se fija una vez, y aquí eso es justo lo correcto, porque lo que cambia es el interior del store, no la tupla.

Consumir: reactividad de grano fino

El consumidor llama al hook, desestructura estado y acciones, y usa ambos con naturalidad. La reactividad de grano fino del store hace el resto.

function ResumenCarrito() {
  const [carrito, { vaciar }] = useCarrito();
  return (
    <div>
      <span>Artículos: {carrito.lineas.length}</span>
      <button onClick={vaciar}>Vaciar</button>
    </div>
  );
}

Aquí está la joya que Solid regala y que en React costaría cuidado manual: este componente solo se recomputa en la parte que leyó. carrito.lineas.length es una lectura de grano fino; cuando cambia la cantidad de una línea, se actualiza ese span y nada más. Otro componente que lea carrito.lineas[2].precio no se inmuta si cambia la línea 0. No hay re-render del consumidor, no hay comparación de props, no hay memoización defensiva: el store notifica exactamente a quien leyó exactamente lo que cambió.

flowchart TD
PROV[CarritoProvider crea el store] --> CTX[Context lleva la tupla estado y acciones]
CTX --> R[ResumenCarrito lee lineas length]
CTX --> L[ListaLineas lee cada linea]
CTX --> B[BotonAgregar usa la accion agregar]
B -->|muta via setEstado| PROV
PROV -.grano fino notifica solo al lector afectado.-> L
style PROV fill:#89b4fa,color:#11111b
style B fill:#fab387,color:#11111b
style L fill:#a6e3a1,color:#11111b

Podrías proveer varios signals sueltos, pero el store gana en cuanto el estado es un objeto o una lista. Un store ofrece reactividad de grano fino sobre estado anidado: leer estado.lineas[i].cantidad suscribe solo a esa hoja, y setEstado con su ruta actualiza solo esa hoja. Un solo contexto puede así albergar un estado rico —decenas de campos anidados— sin que tocar uno despierte a los lectores de otro. Con signals sueltos tendrías que trocear el estado a mano y proveer muchos; el store lo hace por ti y mantiene el contexto en una sola tupla limpia.

Alcance de subárbol e instancias propias

Como el store nace dentro del Provider, cada instancia del Provider tiene su propio store. Un CarritoProvider alrededor de toda la app da un carrito global; dos CarritoProvider en dos rincones dan dos carritos independientes. Esto convierte el patrón en algo más versátil que un simple estado global: es estado con alcance, tan amplio o tan acotado como el subárbol que envuelvas. Un asistente por pasos, un panel, una fila editable de una tabla —cada uno puede tener su propio Provider y su propio estado aislado del vecino.

Y como el store cuelga del owner del Provider, su ciclo de vida es automático: cuando el subárbol se desmonta, el owner se dispone, y con él el store y cualquier efecto que abriera. No hay estado que limpiar a mano; la disposición jerárquica del árbol de owners se encarga. Estado compartido, reactivo, con alcance y autolimpieza, en unas veinte líneas.