Vue Router et Pinia : quand (et pourquoi) structurer une SPA

Une appli Vue dépasse vite le stade du composant unique. Il faut alors :

• des routes pour naviguer sans recharger la page (Vue Router) ;
• un état partagé entre pages et composants (Pinia, successeur recommandé de Vuex).

Sans ça, on propage des props sur dix niveaux ou on duplique des données. Avec trop tôt / trop mal, on obtient l’inverse : une usine à gaz.

L’erreur n°1 : Pinia pour tout (et pour n’importe quoi)

Pinia n’est pas un remplacement de la réactivité locale. Un compteur dans un seul composant n’a pas besoin d’un store. Un panier partagé entre header, page produit et checkout : oui.

Règle simple que je donne en formation :

• état local → ref / reactive dans le composant ;
• état partagé entre plusieurs vues → store Pinia ;
• données qui vivent surtout côté serveur → API + cache localisé, pas un monolithe Pinia.

L’erreur n°2 : Router sans penser aux URLs

Des routes « techniques » (/page1, /comp2) ou des navigations uniquement programmatiques sans URLs partageables : mauvais réflexe. Une SPA bien faite reste navigable (favoris, refresh, partage de lien).

Ce qui compte vraiment avec Vue Router :

• routes nommées et paramètres dynamiques ;
• queries pour les filtres ;
• routes imbriquées quand le layout le justifie ;
• lazy loading des vues lourdes ;
• navigation guards pour l’auth (équivalent frontend des middlewares Laravel).

Deux patterns minimaux

Route dynamique :

// router/index.js
const routes = [
{ path: '/rooms/:id', name: 'room.show', component: RoomShow },
]

Store Pinia minimal :

// stores/cart.js
import { defineStore } from 'pinia'
export const useCartStore = defineStore('cart', {
state: () => ({ items: [] }),
actions: {
addItem(room) {
this.items.push(room)
},
},
})

Ce sont les briques que vous retrouverez dans une SPA branchée sur une API Laravel, panier, session utilisateur, filtres persistants, etc.

Quand les introduire dans votre parcours

Prérequis : être à l’aise avec Vue.js 3 (composants, réactivité, Composition API). Sinon, commencez par cet article sur Vue.js 3.

Bon moment pour Router + Pinia :

• vous avez plusieurs écrans avec des URLs distinctes ;
• plusieurs composants doivent lire / écrire les mêmes données ;
• vous préparez une intégration Laravel (auth, panier, API).

Mauvais moment :

• vous débutez encore sur les props et les computed ;
• votre « appli » tient en une seule vue.

Comment je structure l’apprentissage

Je suis la doc officielle Vue Router et Pinia, dans cet ordre : routes → navigation → guards → stores → architecture. Toujours avec des exemples qui grossissent, pas une checklist de concepts isolés.

L’objectif n’est pas de « connaître Pinia », c’est de savoir où placer l’état et comment naviguer sans se peindre dans un coin.

Ressources gratuites

• Playlist : Maîtrisez Vue Router
• Playlist : Maîtrisez Pinia
• Voir ma formation web Udemy sur le sujet : Vue.js : tutoriels, vidéos et formations

Pour un parcours vidéo dédié (routes, guards, stores modulaires), le détail est ici : formation Vue Router & Pinia.

Pour aller plus loin

• Comment relier Laravel et Vue.js ? : API, panier, architecture fullstack ;
• Apprendre Laravel sans se perdre : côté backend ;
• Pack fullstack Laravel & Vue.js : si vous visez le stack complet.

Conclusion

Vue Router et Pinia transforment une collection de composants en application structurée. Ce ne sont pas des gadgets, ce sont les outils qui séparent un prototype d’un frontend maintenable, surtout avant de connecter Vue à Laravel.

Introduisez-les au bon moment, pour les bons problèmes : c’est là que le gain est réel.