vue-router-best-practices

Présentation de la compétence vue-router-best-practices

Ce que la compétence vue-router-best-practices aide à résoudre

La compétence vue-router-best-practices est un guide ciblé de dépannage et de mise en œuvre pour Vue Router 4, en particulier sur les navigation guards, les changements de paramètres de route et le comportement du cycle de vie des composants liés aux routes. Elle est surtout utile si votre application utilise déjà Vue 3 + Vue Router et que vous avez besoin rapidement de patterns corrects, pas de conseils génériques sur le framework.

À qui cette compétence s’adresse

Cette compétence convient aux développeurs frontend qui :

• livrent des routes protégées par authentification ou permissions
• déboguent des données obsolètes quand seuls les paramètres de route changent
• migrent un ancien code de guards qui utilise encore next()
• cherchent à éviter les boucles de redirection et les bugs de routage silencieux

Si votre vrai sujet est de « rendre le routage sûr et prévisible en production », cette compétence sera plus pertinente qu’un prompt Vue généraliste.

Pourquoi cette compétence se distingue d’un prompt générique

La valeur de vue-router-best-practices tient au fait qu’elle se concentre sur un petit ensemble de pièges Vue Router à fort impact, qui cassent régulièrement de vraies applications :

• beforeEnter ne se relance pas lors des mises à jour de paramètres ou de query
• beforeRouteEnter n’a pas accès à this
• une logique de guard asynchrone qui ne bloque pas réellement la navigation
• des redirections infinies dans les guards globaux
• un état de composant obsolète quand les paramètres de route changent
• des patterns next() dépassés dans Vue Router 4

C’est ce qui rend cette compétence particulièrement utile pour corriger des bugs, faire des revues de code et accompagner des migrations.

Ce que la compétence ne cherche pas à couvrir

Ce n’est ni un cours complet sur Vue Router, ni une référence exhaustive de l’API de routage, ni un guide d’architecture couvrant tous les modes du routeur. La compétence est volontairement resserrée : elle aide sur des problèmes concrets de fiabilité qui affectent le vrai comportement de navigation.

Comment utiliser la compétence vue-router-best-practices

Contexte d’installation pour vue-router-best-practices

Utilisez vue-router-best-practices dans un workflow de code assisté par IA où le modèle peut inspecter votre configuration de routeur, vos composants de route et votre logique de guards. La compétence se trouve dans skills/vue-router-best-practices du dépôt vuejs-ai/skills :

• SKILL.md
• reference/router-beforeenter-no-param-trigger.md
• reference/router-beforerouteenter-no-this.md
• reference/router-guard-async-await-pattern.md
• reference/router-navigation-guard-infinite-loop.md
• reference/router-navigation-guard-next-deprecated.md
• reference/router-param-change-no-lifecycle.md
• reference/router-simple-routing-cleanup.md
• reference/router-use-vue-router-for-production.md

Si votre plateforme prend en charge l’installation de skills, utilisez son flux habituel d’ajout ou d’import du dépôt, puis ciblez vue-router-best-practices.

Lisez d’abord ces fichiers avant de lancer un prompt

Pour comprendre le plus vite possible, lisez dans cet ordre :

1. SKILL.md
2. reference/router-navigation-guard-next-deprecated.md
3. reference/router-navigation-guard-infinite-loop.md
4. reference/router-param-change-no-lifecycle.md
5. reference/router-beforeenter-no-param-trigger.md

Cet ordre de lecture met d’abord en avant les erreurs les plus risquées : contrôle de flux cassé dans les guards, boucles de redirection et données obsolètes pilotées par la route.

De quelles entrées la compétence a besoin

La vue-router-best-practices skill donne les meilleurs résultats si vous fournissez du code de routage concret, pas seulement un symptôme. Entrées utiles :

• router/index.ts ou router.ts
• des route records avec meta
• des guards globaux comme beforeEach
• des guards dans les composants
• des composants rendus par des routes dynamiques comme /users/:id
• une courte reproduction de ce que la navigation devrait faire vs ce qu’elle fait actuellement

Sans code, la réponse sera plus générique et moins fiable.

Transformer un problème vague en prompt solide

Prompt faible :

• « Mon Vue Router a des bugs. Aide-moi. »

Prompt solide :

• « Use vue-router-best-practices to review this Vue Router 4 setup. When navigating from /orders/1 to /orders/2, access checks do not rerun and stale order data remains visible. We use a route-level beforeEnter, an async beforeEach, and onMounted in OrderDetail.vue. Identify the bug sources, explain which Vue Router behaviors are causing them, and rewrite the guards and component logic using Vue Router 4 return-based patterns. »

Cette version donne au modèle suffisamment de structure pour appliquer le bon fichier de référence et produire une correction exploitable.

Workflow conseillé pour utiliser vue-router-best-practices

Un workflow pratique :

1. Collez la configuration de route et le code des guards qui posent problème.
2. Décrivez exactement le parcours de navigation qui échoue.
3. Demandez au modèle d’associer votre problème à l’un des pièges connus.
4. Demandez une implémentation corrigée.
5. Demandez une courte checklist de test couvrant l’accès direct, les changements de paramètres sur la même route, les redirections et les accès non autorisés.

Cette approche fonctionne mieux que de demander des « bonnes pratiques » dans l’abstrait, car la plupart des bugs Vue Router dépendent du scénario précis.

Cas d’usage où cette compétence est la plus utile

Les meilleurs cas d’usage de vue-router-best-practices sont :

• le routage lié à l’authentification et aux rôles
• les pages de détail pilotées par des paramètres de route
• le nettoyage d’une migration de Vue Router 3 vers 4
• le débogage d’instances de composants réutilisées
• le remplacement d’un contrôle de flux fragile basé sur next()
• la revue de la bonne place pour la logique de guard : globale, par route ou dans le composant

Patterns courants que la compétence peut corriger

Attendez-vous à ce que cette compétence vous aide à trancher entre :

• beforeEach vs beforeEnter vs onBeforeRouteUpdate
• watch(() => route.params.id) vs forcer un remount avec :key
• guards basés sur les valeurs de retour vs next() déprécié
• récupération des données au niveau composant vs pré-vérifications au niveau guard
• Vue Router vs simple routage hash pour les applications en production

Il s’agit de vrais choix d’implémentation, pas de simples recommandations de style.

Modèle de prompt pratique pour de meilleurs résultats

Utilisez ce modèle pour obtenir de meilleurs résultats avec le guide vue-router-best-practices :

• “Use vue-router-best-practices on this Vue 3 app.”
• “Environment: Vue 3, Vue Router 4, Composition API.”
• “Problem: [describe exact navigation bug].”
• “Expected behavior: [what should happen].”
• “Current behavior: [what actually happens].”
• “Files: [paste router config and affected component].”
• “Please: identify the Vue Router gotcha, explain why it happens, propose the safest fix, and include edge cases to test.”

Conseils qui améliorent réellement la qualité des réponses

Donnez au modèle ces informations si vous les avez :

• si la route change de chemin ou seulement de paramètres/query
• si le composant est réutilisé d’un ID à l’autre
• si l’authentification est synchrone ou dépend d’une API
• si vous utilisez l’Options API ou la Composition API
• si le code dépend encore de next()

Ces détails déterminent directement quels conseils d’installation et d’usage de vue-router-best-practices s’appliquent.

FAQ sur la compétence vue-router-best-practices

La compétence vue-router-best-practices convient-elle aux débutants ?

Oui, si vous connaissez déjà les bases de Vue et avez besoin d’aide sur des comportements de routage peu évidents. Ce n’est pas une introduction pas à pas à Vue Router, mais elle reste accessible aux débutants confrontés à des erreurs de production courantes, car les références sont organisées autour de bugs précis et de leurs correctifs.

Quand l’utiliser plutôt qu’un prompt de code classique ?

Utilisez vue-router-best-practices quand le problème concerne les transitions de route, le timing des guards, les composants de route réutilisés ou le comportement des redirections. Un prompt classique peut proposer du code plausible, mais cette compétence a plus de chances d’identifier les cas limites propres à Vue Router, comme une navigation avec changement de paramètres uniquement qui ne relance pas beforeEnter.

Cette compétence couvre-t-elle spécifiquement Vue Router 4 ?

Oui. Le contenu source cible explicitement les patterns de Vue Router 4, y compris la migration depuis le style next() déprécié vers des guards basés sur des valeurs de retour.

Quels sont les principaux risques qu’elle aide à éviter ?

Les problèmes les plus importants qu’elle aide à prévenir sont :

• des accès non autorisés parce que les guards ne se relancent pas
• des données de page obsolètes lors de changements de paramètres
• des vérifications de navigation asynchrones bloquées ou déclenchées au mauvais moment
• des boucles de redirection infinies
• des incompréhensions de cycle de vie dans beforeRouteEnter

Quand cette compétence est-elle un mauvais choix ?

Évitez cette compétence si votre problème concerne surtout :

• le routage SSR avec des abstractions propres à un framework
• l’architecture générale des composants Vue sans lien avec la navigation
• un tutoriel complet sur le routage depuis les bases
• des bibliothèques de routage frontend non liées à Vue

C’est une compétence vue-router-best-practices for Frontend Development ciblée, pas un manuel universel du routage.

Comment améliorer la compétence vue-router-best-practices

Donnez des scénarios de navigation, pas seulement des dumps de code

Pour améliorer les réponses de vue-router-best-practices, décrivez la transition de route exacte :

• depuis quelle URL
• vers quelle URL
• si seuls les paramètres/query ont changé
• si l’utilisateur doit être redirigé, bloqué ou autorisé

C’est important, car beaucoup de bugs Vue Router n’apparaissent que sur un seul parcours de navigation.

Incluez à la fois le code du routeur et celui du composant

Un mode d’échec fréquent consiste à ne diagnostiquer que la moitié du problème. Par exemple, un route guard peut être correct alors que le composant s’appuie encore sur onMounted et affiche des données obsolètes lors du passage de /users/1 à /users/2. Incluez les deux fichiers pour que la compétence puisse relier la logique des guards au comportement du cycle de vie du composant.

Demandez une décision, pas seulement un correctif

Meilleur prompt :

• « Cette logique doit-elle vivre dans beforeEach, beforeEnter, onBeforeRouteUpdate ou un watch, et pourquoi ? »

Cette demande produit une réponse plus solide que « corrige ce bug », car la compétence est particulièrement utile pour choisir la bonne couche de routage.

Surveillez ces modes d’échec fréquents

Les points les plus courants à vérifier après la première réponse :

• le correctif suppose encore que beforeEnter se déclenche lors des changements de paramètres
• la solution mélange next() et des patterns basés sur des valeurs de retour
• la redirection d’auth peut encore cibler la route courante
• les vérifications asynchrones sont bien attendues, mais les erreurs/timeouts ne sont pas gérés
• les données obsolètes sont corrigées via un remount forcé alors qu’un simple watch aurait suffi

Demandez une checklist de test après le correctif

Une bonne étape d’amélioration consiste à demander :

• « Maintenant, donne-moi une checklist de test minimale pour une visite directe, une visite authentifiée, une redirection non authentifiée, un changement de paramètres sur la même route, un changement de query et un ID invalide. »

C’est particulièrement important dans l’usage de la vue-router-best-practices skill, car beaucoup de bugs de routage n’apparaissent qu’une fois le scénario nominal initial validé.

Utilisez les références comme outils de relecture ciblés

Après avoir obtenu une première réponse, demandez au modèle de la valider par rapport à la référence la plus pertinente :

• router-beforeenter-no-param-trigger.md
• router-navigation-guard-infinite-loop.md
• router-param-change-no-lifecycle.md

Cette seconde passe permet souvent de repérer des erreurs subtiles et d’augmenter le niveau de confiance avant de modifier du code de routage en production.