Déplacer l’affichage en composants serveur

Une fiche d’itinéraire peut afficher des informations qui ne réagissent à aucune action : son nom, sa description et son image. Si ces éléments sont rendus par un composant client sans nécessité, vous ajoutez du JavaScript à transférer et à traiter pour une présentation qui pourrait être produite sur le serveur. Dans cette leçon, vous isolez l’affichage statique du détail dans le composant serveur du projet. La page conserve ses métadonnées, ses données structurées, son traitement des slugs inconnus et la diffusion progressive déjà vérifiée dans les leçons précédentes.

Repérer ce qui doit rester côté serveur

Un composant serveur est le choix adapté lorsqu’une partie de la page présente des données sans gérer d’interaction dans le navigateur. Dans l’App Router, les composants restent des composants serveur par défaut : vous n’ajoutez donc pas de directive particulière pour obtenir ce comportement. La frontière serveur-client désigne l’endroit où des éléments nécessitant du code exécuté dans le navigateur sont introduits ; cette leçon ne crée pas une telle frontière.

Le fichier du projet app/randonnees/[slug]/itineraire.tsx est l’emplacement prévu pour l’affichage détaillé. Vous pouvez y garder le balisage de la fiche et recevoir les valeurs déjà obtenues par la page. Les données sérialisées entre composants sont les valeurs transmises sous une forme que Next.js peut faire circuler entre les parties serveur et client ; ici, vous transmettez simplement des chaînes de caractères, sans ajouter de données ni de comportement client.

Conserver l’affichage dans le composant serveur

Voici un composant complet qui rend le détail sans état d’interface ni gestionnaire d’événement. Il utilise uniquement les classes prévues par le contrat. Les propriétés décrivent le contenu affiché ; dans votre application, la page leur transmet les valeurs de l’itinéraire déjà sélectionné par son slug.

type ItineraireProps = {
  nom: string;
  description: string;
  image: string;
  texteAlternatif: string;
};

export default function Itineraire({
  nom,
  description,
  image,
  texteAlternatif
}: ItineraireProps) {
  return (
    <article className="rando-detail" aria-labelledby="titre-itineraire">
      <h1 id="titre-itineraire">{nom}</h1>
      <div className="rando-detail__media">
        <img src={image} alt={texteAlternatif} />
      </div>
      <p>{description}</p>
    </article>
  );
}

Aucune directive use client ne figure en tête de ce fichier : le composant reste donc serveur. Il ne manipule pas directement le DOM ; il décrit le balisage que Next.js rend pour la page. L’extrait constitue le fichier complet de présentation, et non un remplacement partiel de lignes. Il n’importe pas de feuille de style supplémentaire et conserve les classes contractuelles.

Transmettre les valeurs depuis la page

La page dynamique reste responsable de la sélection de l’itinéraire et de ses contrôles existants. Elle rend le composant de détail à l’endroit où celui-ci était déjà placé, en lui transmettant le nom, la description, le chemin de l’image et son texte alternatif issus de l’objet de randonnée. Conservez les noms de propriétés réellement fournis par lib/randonnees.ts : ne dupliquez pas les données dans le composant et ne modifiez ni la génération des métadonnées ni le JSON-LD.

La frontière Suspense et son fallback restent en place autour de la partie asynchrone, conformément à l’état du projet. Si la fiche détaillée est rendue par un composant asynchrone, gardez cette attente dans le composant serveur qui charge les données ; la conversion de son balisage statique ne doit pas supprimer la suspension ni déplacer le fallback. Le flux de rendu progressif a déjà été contrôlé sur la route des Crêtes du Jura.

Vérifier le résultat et le budget

Lancez le serveur de développement, puis ouvrez /randonnees/cretes-du-jura. Vérifiez que le titre, l’image et la description apparaissent comme auparavant, que l’image conserve un texte alternatif pertinent et que le fallback reste visible si le chargement asynchrone est suffisamment lent. Contrôlez également qu’un slug inconnu suit toujours le traitement déjà prévu et que les métadonnées et le bloc JSON-LD correspondent toujours à l’itinéraire affiché.

Sur un build de production, comparez le JavaScript client de la route avec le budget et la référence consignés dans la leçon « Fixer un budget de JavaScript client ». Le déplacement du rendu statique vers un composant serveur ne garantit pas à lui seul une baisse précise : mesurez le résultat, contrôlez le waterfall et rejetez toute régression Lighthouse selon la règle du projet. Consignez les conditions de mesure et vérifiez que le changement n’a pas ajouté de code navigateur inutile.

À retenir

• L’affichage statique de la fiche reste dans un composant serveur par défaut, sans directive client.
• La page transmet au composant de détail les seules valeurs nécessaires à son rendu.
• La conversion conserve la frontière Suspense, le fallback, les métadonnées, le JSON-LD et les contrôles des slugs inconnus.
• Vous vérifiez le JavaScript client et Lighthouse sur un build de production, par comparaison avec la référence.

Dans la prochaine leçon, vous réserverez les composants client aux interactions qui en ont réellement besoin.