Routeur d'application Next.js : le guide pour penser serveur par défaut

Lorsque Next.js a lancé App Router, il a fait quelque chose qui semble technique mais qui est, en substance, une décision de mentalité : il a inversé le modèle. Avant, chaque composant appartenait au client jusqu'à ce que vous disiez le contraire. Désormais, chaque composant est côté serveur jusqu'à ce que vous vérifiiez qu'il doit être côté client.

Cette inversion est petite en syntaxe et énorme en pratique. Cela change la question que l'équipe pose à chaque composant. Au lieu de supposer que tout s'exécute dans le navigateur, vous justifiez pourquoi quelque chose devrait s'y exécuter.

Pour ceux qui viennent de React traditionnel, l'App Router n'est pas simplement un nouveau dossier avec un routeur différent. C'est une invitation à repenser l'endroit où devrait se trouver chaque élément de l'application. Et cette invitation a tendance à désorienter avant d’avoir un sens.

La tendance s'est inversée

Dans App Router, les mises en page et les pages sont des composants de serveur par défaut. Cela signifie que lorsque vous créez une nouvelle page, elle démarre sur le serveur, sans que vous fassiez quoi que ce soit. Son code ne va pas au navigateur et la recherche de données peut avoir lieu directement, avant que la réponse ne soit émise.

La conséquence immédiate est que beaucoup de choses que vous pouviez transmettre au client restent désormais naturellement sur le serveur. La liste des produits, le contenu de l'article, l'en-tête avec les données utilisateur, tout cela est rendu avant d'arriver, sans frais JavaScript sur l'appareil.

Lorsque vous avez besoin d'interactivité, vous marquez le composant avec la directive "use client". À partir de ce moment, ce composant et ce qu'il restitue commencent à s'exécuter dans le navigateur, avec leur état et leurs événements. Il s'agit d'une limite explicite, pas d'un accident.

L’effet secondaire sain est que le client devient une exception consciente. On n’y tombe pas par inertie, on choisit quand y entrer. Si cela semble encore abstrait, cela vaut la peine de revoir ce que sont les composants React Server](/post/o-que-sao-react-server-components) avant de continuer.

Quand le composant doit être serveur

La bonne question concerne la nature du travail. Si le composant recherche et affiche uniquement des informations, il a tout pour être un serveur. Pages de listing, contenu de blog, détails de commande, tableaux de bord qui n'affichent que des chiffres : rien de tout cela n'a besoin du navigateur pour exister.

Les composants du serveur brillent dans la récupération de données. Vous consultez directement la banque, appelez les services internes avec la faible latence de ceux au sein de l'infrastructure et créez le résultat final. Vous n'avez pas besoin d'une route API intermédiaire uniquement pour que le navigateur puisse demander les données, car le composant est déjà sur le côté droit.

Il y a aussi l'avantage de réduire le poids du client. Bibliothèques de formatage lourdes, traitement des démarques, manipulation des dates : si cela s'exécute sur le serveur, il n'entre jamais dans le package que l'utilisateur télécharge. Le paquet diminue et l'appareil de l'utilisateur vous remercie.

La règle mentale qui fonctionne est la suivante : commencez par reprendre le serveur. Ne vous adressez au client que lorsqu’il existe un besoin concret d’interaction. Résister à l’envie de tout qualifier de client représente la moitié de la bataille.

Lorsque le composant doit être côté client

Tout ne tient pas sur le serveur, et essayer de forcer cela entraîne de la frustration. Il existe un ensemble clair de situations qui nécessitent des clients, et les reconnaître rapidement évite de perdre du temps.

Le premier est l’état qui change à l’écran. Un compteur, un onglet sélectionné, un menu qui s'ouvre et se ferme : tout ce qui a besoin de retenir quelque chose entre les interactions vit dans le client. Le second est l’événement utilisateur. Cliquer, taper, faire glisser, toute manipulation directe se produit dans le navigateur, car c'est là que se trouve l'utilisateur.

Le troisième est l'utilisation des ressources du navigateur. L'accès au stockage local, la géolocalisation, la taille de la fenêtre de lecture, tout ce qui n'existe que dans l'environnement du navigateur nécessite que le composant soit côté client. Il n'y a aucun moyen de l'exécuter sur le serveur, simplement parce que le serveur n'a ni fenêtre ni souris.

Le détail qui libère l'esprit de l'équipe est de comprendre que ce n'est pas tout ou rien. Vous pouvez avoir une page serveur qui affiche un petit composant client uniquement pour le bouton interactif. Le reste de la page reste léger et rendu sur le serveur. L'interactivité est isolée là où elle compte vraiment, au lieu de contaminer la page entière.

La recherche de données change d'emplacement

Dans l'ancien modèle, la récupération des données était un rituel bien connu : le composant s'assemblait, déclenchait un effet, appelait une API, gérait les états de chargement et d'erreur, et mettait à jour l'état lorsque la réponse revenait. Cela a fonctionné, mais c’était verbeux et semé d’embûches.

Avec les composants serveur, la récupération des données redevient simple. Vous récupérez les données lors du rendu sur le serveur, attendez le résultat sur place et renvoyez l'interface prête à l'emploi. Ajoutez une grande partie de la danse des états de chargement au client, car les données arrivent déjà avec la page.

Cela simplifie le code et améliore en même temps l’expérience, ce qui est rare. L'utilisateur reçoit un contenu déjà rempli, sans que cette séquence d'écrans vides ne clignote pendant le chargement de chaque partie. Et lorsque vous avez besoin d'un chargement progressif, le framework propose un streaming pour fournir les morceaux dès qu'ils sont prêts, un sujet qui mérite d'être approfondi mise en cache et streaming dans Next.js.

La mutation des données suit une logique similaire. Au lieu de créer une API complète pour chaque formulaire, vous pouvez utiliser des actions serveur, des fonctions qui s'exécutent sur le serveur et sont appelées directement depuis l'interface. Cela clôt le cycle : lire et écrire au plus près de la source, sans couches qui n'existaient que pour servir le navigateur.

Le changement de mentalité auquel l'équipe est confrontée

Le plus difficile avec App Router n’est pas la syntaxe. C'est désapprendre le réflexe selon lequel tout s'exécute dans le navigateur. Les équipes expérimentées dans React ont tendance à marquer les composants comme clients par habitude, car c'est ainsi qu'elles ont appris, et elles perdent alors une grande partie du gain.

Le symptôme classique est le "use client" en haut de presque tous les fichiers. Lorsque cela se produit, l’application redevient un SPA déguisé, avec le poids d’avant et la nouvelle complexité en tête. L'équipe doit comprendre que chaque rendez-vous client est une décision à justifier et non un modèle à copier.

Il y a également un ajustement mental sur l'endroit où le code s'exécute. Penser qu'une partie de l'arborescence s'exécute sur le serveur et une autre sur le navigateur nécessite de prêter attention à ce que chaque partie peut faire. Essayer d'utiliser une fonctionnalité de navigateur dans un composant serveur génère des erreurs, et ces premiers faux pas font partie de l'apprentissage normal.

Une fois le centime tombé, le modèle devient intuitif. La question de savoir si cette interaction doit devenir automatique et l'équipe commence à concevoir des interfaces légères par défaut. Mais pour y parvenir, il faut un leadership technique prêt à réviser patiemment le code et à corriger les vieux réflexes.