# Séance 6-b : Introduction à Nuxt 3

## 🎯 Objectifs

* Découvrir Nuxt et ses apports (SSR, SSG, SEO).
* Migrer une app Vue vers Nuxt.

## Qu'est-ce que Nuxt.Js ?

Nuxt (<https://nuxt.com/>), vesion 4 aujourd'hui, est un framework construit au‑dessus de Vue 3 qui facilite la création d'applications universelles (fullstack) : sites statiques, applications server‑rendered (SSR) ou applications hybridées. Nuxt vise à fournir une structure et des conventions pour accélérer le développement (routing automatique, layouts, plugins, modules, import automatisés, ...). Sa runtime moderne repose sur Nitro (moteur serveur agnostique) et offre un excellent support pour le rendu côté serveur, le prerendering, le déploiement serverless et l'optimisation des performances.

Points clés de Nuxt 3 / 4 :

* Routing automatique via `pages/`.
* Layouts et slots globaux via `layouts/`.
* API server intégrée via `server/` (endpoints API côté serveur).
* Nitro : abstraction du serveur.
* Modules & plugins pour étendre les fonctionnalités (auth, i18n, analytics).
* Support SSR, SSG et ISR (hybride) natif.
* Intégration simple avec Vite, TypeScript et Pinia.

### Comparatif Nuxt vs Vue (grand lignes)

* Vue :
  * Framework UI (lib) pour construire des interfaces réactives côté client.
  * Idéal pour des applications SPA où l'on contrôle la configuration et l'outillage.
  * Nécessite d'ajouter manuellement routing, SSR/SSG, structure de dossiers si besoin.
* Nuxt :
  * Framework construit sur Vue, fournit conventions et scaffolding.
  * Ajoute des fonctionnalités prêtes à l'emploi : SSR/SSG, routage automatique, API server.
  * Réduit la configuration initiale, facilite le SEO et le déploiement sur des plateformes serverless.

**Quand choisir Nuxt ?**

* Projet nécessitant SEO, SSR ou génération statique.
* Besoin d'une structure rapide, modules prêts à l'emploi et déploiement serverless.

**Quand choisir Vue seul ?**

* Projet front uniquement où SSR/SSG n'est pas nécessaire.
* Besoin d'une configuration fine et légère, ou intégration dans une architecture existante.

### Modes de rendu — tableau synthétique

| Mode                                                 | Description courte                                                                    | Avantages                                                      | Inconvénients                                            | Cas d'usage                                      |
| ---------------------------------------------------- | ------------------------------------------------------------------------------------- | -------------------------------------------------------------- | -------------------------------------------------------- | ------------------------------------------------ |
| CSR (Client‑Side Rendering)                          | Le rendu HTML est généré côté client par le navigateur après téléchargement des JS    | Interactions rapides après initial load ; développement simple | Mauvais SEO, temps au premier rendu plus long            | SPA internes, dashboards authentifiés            |
| SSR (Server‑Side Rendering)                          | Le serveur renvoie du HTML pré‑rendu pour chaque requête                              | Meilleur SEO, premier rendu rapide, partage social (meta)      | Charge serveur plus importante, complexité (hydration)   | Sites publics, e‑commerce, blogs dynamiques      |
| SSG (Static Site Generation)                         | Pages générées à la build en HTML statique (prérendu)                                 | Très performant, sécurisé, scale gratuit (CDN)                 | Moins adapté au contenu très dynamique sans revalidation | Documentation, blogs, landing pages              |
| ISR (Incremental Static Regeneration) / Revalidation | SSG + possibilité de régénérer des pages après build (à la demande ou périodiquement) | Meilleure cohérence entre perf et dynamique                    | Complexité additionnelle, dépend du provider             | Sites commerce avec catalogue mis à jour souvent |
| Edge Rendering / SSR\@Edge                           | Rendu SSR exécuté côté edge (CDN) proche de l'utilisateur                             | Très faible latence, meilleure SEO globalement                 | Support dépendant du provider et du runtime              | Sites internationaux, latence critique           |

***

### Structure Nuxt

Pour que Nuxt fonctionne de manière optimale, il faut respecter une certaine structure de dossiers. Voici les principaux répertoires et fichiers :

* `pages/` : routage automatique (chaque fichier = route)
* `layouts/` : templates globaux (ex : default, auth)
* `components/` : composants réutilisables
* `composables/` : composables auto‑importés
* `plugins/` : registres et initialisations (ex : axios, i18n)
* `server/` : endpoints server (API) et middleware
* `app.vue` / `nuxt.config.ts` : configuration globale

La documentation ici est très explicite : <https://nuxt.com/docs/4.x/guide/directory-structure/app/app>

**/!\ Depuis la version 4, la structure est déportée dans un dossier `app/` pour plus de flexibilité.**

### Modules Nuxt

Nuxt dispose d'un écosystème riche de modules (<https://nuxt.com/modules>) pour ajouter des fonctionnalités courantes facilement, par exemple :

* Authentification (ex : `@nuxtjs/auth-next`)
* Internationalisation (i18n) (ex : \`@nuxtjs/i18n
* Analytics (ex : `@nuxtjs/google-analytics`)
* CMS (ex : `@nuxtjs/content`)
* ...

## Routage avec Nuxt

Le routage dans Nuxt (<https://nuxt.com/docs/4.x/getting-started/routing>) est automatique via le dossier `pages/`. Chaque fichier `.vue` dans ce dossier devient une route accessible. Il est possible de créer des routes dynamiques, imbriquées, et de configurer des meta‑tags via la propriété `definePageMeta`.

Voici quelques exemples :

* `pages/index.vue` → `/`
* `pages/about.vue` → `/about`
* `pages/blog/index.vue` → `/blog`
* `pages/blog/[id].vue` → `/blog/:id` (route dynamique)
* `pages/dashboard/settings.vue` → `/dashboard/settings` (route imbriquée)
* `pages/user/[...slug].vue` → `/user/*` (catch-all)

`definePageMeta` pour configurer les meta‑tags SEO (<https://nuxt.com/docs/4.x/getting-started/seo-meta#usehead>)

```js
<script setup>
useHead({ 
  title: 'Page Title',
  meta: [
	{ name: 'description', content: 'Page description for SEO' }
  ]
})
</script>
```

/!\ definePageMeta dans la version 3 de Nuxt.

## Exercice

Migrer une application Vue 3 existante vers Nuxt 4 :

1. Créer un nouveau projet Nuxt 4 (`npm create nuxt@latest`).
2. Déplacer et adapter vos fichiers
3. Les composables, services et stores Pinia doivent être placés dans `composables/`, `services/` et `stores/` respectivement.
4. Les views (pages) doivent être placées dans `pages/` avec le routage automatique. Vous pourrez retirer les imports et configurations de Vue Router.

La sécurité, avec Nuxt, (authentification, autorisation) sera vue dans la séance suivante.