Next.js App Router
Préservez la version prise en charge et la configuration de l'application. Privilégiez le rendu serveur et les lectures directes du serveur là où cela convient ; conservez le comportement interactif et en direct du navigateur là où il est nécessaire.
Établir le contexte
Inspectez package.json, le fichier de verrouillage, les dossiers de routes, next.config.* et les instructions du projet. Identifiez les versions installées de Next.js/React, l'utilisation de l'App Router par rapport au Pages Router, les contraintes d'exécution/déploiement et si Cache Components est activé. Dans les monorepos, résolvez ces éléments à partir de l'application concernée. Ne mettez pas à jour les packages et n'activez pas de fonctionnalités simplement pour correspondre à un exemple.
Privilégiez la documentation correspondant à la version, disponible dans node_modules/next/dist/docs/ sur Next.js 16.2+, lorsqu'elle est disponible. Sinon, consultez la documentation officielle pour la version prise en charge. La documentation en direct peut décrire une version mineure plus récente ; vérifiez l'historique de l'API et la configuration avant l'utilisation. Distinguez les API stables, les options expérimentales, les dépréciations et les conventions du projet.
Choisir la ressource pertinente
Lisez uniquement les ressources nécessaires à la tâche ; suivez leurs liens officiels en cas d'incertitude sur une version ou un comportement.
| Tâche | Ressource |
|---|---|
| Limites serveur/client, composition, sérialisation | Composants serveur |
| Lectures, streaming, données navigateur, actions, points d'accès HTTP | Accès aux données |
| Mode cache existant, cache components, cache privé/distant, invalidation | Cache |
| Layouts, routes dynamiques, recherche, routes parallèles/interceptées | Routage |
| Redirections/réécritures de requêtes et portes d'authentification optimistes | Proxy |
| Erreurs attendues, chargement, récupération, sémantique des réponses 404 | Gestion des erreurs |
| Exportations de métadonnées, héritage et intégration SEO | Métadonnées |
| Configuration des images/polices et compromis de chargement | Ressources |
| Migration des Pages vers l'App | Migration |
| Montées de version majeures/mineures délibérées | Changements de version |
Prioriser les décisions
- Protégez les secrets et les données utilisateur. Authentifiez et autorisez les lectures/mutations près des données, validez les entrées non fiables et gardez les données personnelles hors d'un cache partagé incorrectement. Le proxy et la visibilité de l'interface utilisateur ne sont pas une autorisation suffisante.
- Préservez l'exactitude entre les versions et les modes de rendu. Les API de requêtes asynchrones, les prérequis du cache, les conventions de route et les propriétés de récupération dépendent de la version/configuration installée.
- Supprimez les cascades de chargement démontrées et le code client inutile. Parallélisez les tâches indépendantes ; choisissez des limites Suspense qui préservent une UI utile. Le fetching client reste approprié pour le polling, l'état exclusif au navigateur et les mises à jour interactives.
- Ajustez la mise en cache, les préchargements et les indices de ressources en fonction de la fraîcheur, du déploiement et du comportement mesuré. Ce sont des choix, pas des prérequis pour chaque application App Router.
Utilisez les composants serveur pour le travail exclusif au serveur. Ajoutez 'use client' à une limite de module utile pour l'interaction ; il n'a pas besoin d'être une feuille. Utilisez une action serveur pour les mutations de l'interface utilisateur lorsque cela est approprié, ou un gestionnaire de route pour un contrat HTTP (y compris les clients navigateur). Aucun des deux ne remplace l'autorisation.
Valider le changement réel
Exécutez les commandes de vérification de type, lint et build existantes de l'application concernée lorsqu'elles sont disponibles. Testez le comportement qui peut échouer : les requêtes directes authentifiées, l'isolation entre utilisateurs, la fraîcheur après mutation, la navigation dure/soft, les erreurs et le chargement. Ne qualifiez pas un extrait de prêt pour la production lorsque les imports, les helpers d'authentification ou la persistance sont des espaces réservés. Indiquez ce qui a été exécuté et ce qui reste non testé.
Pour les révisions, signalez en priorité les échecs actionnables ainsi que leur portée de version/configuration. Séparez les améliorations optionnelles des problèmes d'exactitude. Pour l'implémentation, expliquez la limite/le mode de cache choisi, le comportement modifié et la vérification.
La revue des sources est limitée, ce n'est pas une certification générale. Consultez SOURCES.md pour les liens canoniques, les versions/configurations applicables, les sections vérifiées, les dates amont et la politique de fraîcheur. Les enregistrements de révision/évaluation pilote du dépôt sont des preuves de maintenance et ne sont pas requis au moment de l'exécution.