Pinia et l'architecture d'un front temps réel

Pinia : l'état qui appartient à l'application

Les composables donnent de l'état par appelant ; certaines données appartiennent à l'application entière (l'utilisateur connecté, le panier, les préférences). C'est le rôle du store Pinia :

export const useCartStore = defineStore('cart', () => {
  const lines = ref<QuoteLine[]>([])                          // state
  const total = computed(() => lines.value.reduce(...))        // getter
  async function addLine(variant: Variant, qty: number) { ... }  // action
  return { lines, total, addLine }
})

Même grammaire que les composables (ref/computed/fonctions) — mais singleton : tous les composants qui appellent useCartStore() voient LE même état. La règle de partage : état local d'une feature → composable ; état transverse de l'app → store. Le projet copilot suit exactement ça : Pinia pour l'app (session, préférences, avec persistedstate), composables pour le copilot.

Le cas d'école : anatomie du front copilot

Le défi : un chat streamé en SSE, une UI générée par le LLM, des tools qui s'exécutent au navigateur, un state synchronisé par patches — sans plat de spaghettis. La réponse, en couches :

[protocole]   sse-stream.ts, ag-ui-protocol.ts   ← parser le flux, typer les événements
[état]        useCopilotRun / Messages / CanvasPanel / Hitl / FrontendTools
              chaque composable possède SA tranche d'état, le run les orchestre
[rendu]       registry ag-ui : spec de bloc validée → composant NuxtUI monté
[pages]       assemblent — et ne savent presque rien

Les trois décisions qui font que ça tient :

1. le protocole est isolé : un seul fichier sait parser du SSE — tout le reste consomme des événements typés (changer de transport ne toucherait qu'un fichier) ;
2. l'état est découpé par responsabilité (les ~25 composables) — pas un « méga-store copilot » que tout le monde mute ;
3. le rendu est déclaratif : les événements muettent l'état, le template dérive de l'état — personne ne touche le DOM à la main. Le flux est à sens unique : événement SSE → état → rendu, la boucle réactive de la leçon 1 à l'échelle d'une app.