SSR, hydratation et les conventions Nuxt

Le rendu universel (la feature qui justifie tout)

Une SPA classique envoie un HTML vide + 2 Mo de JS : blanc à l'écran, invisible pour les crawlers. Nuxt fait du SSR universel :

1. requête → le SERVEUR exécute les composants Vue → HTML complet renvoyé
   (l'utilisateur voit la page immédiatement, le SEO voit tout)
2. le navigateur charge le JS → HYDRATATION : Vue « s'attache » au HTML existant,
   branche réactivité et listeners — la page devient interactive
3. navigations suivantes : côté client (SPA) — plus de rechargement

Le concept à vraiment comprendre est l'hydratation : le composant s'exécute deux fois (serveur puis client), et le HTML des deux exécutions doit coïncider — sinon « hydration mismatch ». Corollaires : pas de window au setup (il n'existe pas sur le serveur — c'est le import.meta.client et le onMounted qu'on utilise partout sur cette plateforme), et pas de valeurs différentes entre les deux passes (l'heure, l'aléatoire).

Les conventions : la structure EST la configuration

Nuxt remplace la configuration par des dossiers signifiants :

• pages/ → le routing : pages/cours/[course]/[...lesson].vue = la route dynamique + catch-all (celle de cette plateforme !) ;
• components/ → auto-importés (avec le piège du pathPrefix qu'on a payé : ui/atoms/UiButton.vue devient UiAtomsUiButton sauf config) ;
• composables/ et utils/ → auto-importés aussi — useProgress() s'utilise sans import ;
• server/ → le backend Nitro (leçon 3) ; middleware/, layouts/, plugins/ — chacun son rôle.

Le contrat : tu suis la convention, Nuxt fait la plomberie (code-splitting par page, préchargement, imports). Tu la refuses, tu te bats contre le framework.