Pinia : un état partagé par toute l'application

Depuis le chapitre 7, le panier de la Librairie est créé dans le composant racine et fourni à ses descendants par provide. Le procédé a fait ses preuves, mais l'application à plusieurs écrans du chapitre précédent en montre les limites. Chaque composant qui touche au panier doit connaître la clé d'injection ; les valeurs fournies sont des ref qu'il faut déballer avec .value, jusque dans les gabarits. Surtout, ce qui n'est pas fourni par la racine vit dans une page : le catalogue est rechargé depuis le serveur chaque fois qu'on y revient, parce que la page qui le détenait a été détruite entre-temps.

Ce chapitre présente Pinia, la bibliothèque officielle de Vue pour l'état partagé : des stores, objets réactifs uniques dans l'application, qu'un composant obtient par un simple appel de fonction. On y range le panier et le catalogue de la Librairie. En chemin, on verra ce qu'il ne faut pas faire avec un store (le déstructurer sans précaution), et pourquoi un composable écrit pour les composants doit être adapté pour servir dans un store.

Le chapitre utilise Pinia 4.0.3. Comme au chapitre précédent, les rendus ont été produits dans Chromium sur les projets construits, et les sorties marquées « test » par Vitest (chapitre 11).

10.1 Où ranger l'état ?

Une donnée qui change, dans une application Vue, peut vivre à quatre endroits.

• Dans un composant une ref du <script setup> : le texte d'un champ, l'ouverture d'un menu. Elle naît et meurt avec le composant.
• Chez un parent qui la transmet par props et reçoit les modifications par événements (chapitre 5). C'est le bon choix tant que la donnée ne descend que d'un ou deux niveaux.
• Fournie par un ancêtre avec provide et inject (chapitre 7) : elle traverse tous les niveaux, mais ne vit pas plus longtemps que l'ancêtre qui la fournit.
• Dans un store : un objet réactif unique pour toute l'application, créé à sa première utilisation et conservé ensuite, quels que soient les composants affichés.

Un module JavaScript qui exporte un objet reactive fait déjà office de store rudimentaire. Pinia y ajoute ce qui manque à une vraie application : l'inspection de chaque store et de chaque action dans Vue DevTools ; un état propre à chaque application, que les tests recréent à neuf ; des extensions (persistance, journal) ; une structure commune à tous les stores, que tout développeur Vue reconnaît.

10.2 Un premier store

La démonstration code/ch10/demo-pinia/ réduit le problème à l'essentiel : deux composants frères, sans lien de parenté, qui partagent un panier. On ajoute Pinia au projet, puis on l'installe dans l'application comme le routeur :

$ npm install pinia@4.0.3

import { createApp } from "vue";
import { createPinia } from "pinia";
import App from "./App.vue";

createApp(App).use(createPinia()).mount("#app");

Un store se déclare avec defineStore, dans un module du dossier src/stores/ :

import { ref, computed } from "vue";
import { defineStore } from "pinia";

export const usePanierStore = defineStore("panier", () => {
  // État : des ref
  const titres = ref([]);

  // Accesseurs (getters) : des computed
  const nombre = computed(() => titres.value.length);

  // Actions : des fonctions
  function ajouter(titre) {
    titres.value.push(titre);
  }
  function vider() {
    titres.value = [];
  }

  return { titres, nombre, ajouter, vider };
});

defineStore ne crée rien : il renvoie une fonction, usePanierStore, dont le nom suit la convention des composables. Le store est créé au premier appel, puis chaque appel suivant renvoie le même objet. Les deux composants l'appellent, chacun de son côté :

<script setup>
import { usePanierStore } from "../stores/panier.js";

const panier = usePanierStore();
const livres = ["Programmation Java", "Le Petit Prince", "L’Étranger"];
</script>

<template>
  <section>
    <h2>Catalogue</h2>
    <button
      v-for="titre in livres"
      :key="titre"
      type="button"
      @click="panier.ajouter(titre)"
    >
      Ajouter « {{ titre }} »
    </button>
  </section>
</template>