Data fetching : useAsyncData, useFetch et le double rendu

Le problème que les composables de fetch résolvent

En SSR, un fetch naïf au setup partirait deux fois (serveur puis client à l'hydratation) — double appel, flash de contenu. Les composables Nuxt règlent ça :

const { data: course } = await useAsyncData(
  `course:${slug}`,                         // ← la CLÉ : identifie la donnée
  () => queryContent(`/courses/${slug}`).find(),
)

Le mécanisme : exécuté sur le serveur, le résultat est sérialisé dans le payload de la page ; à l'hydratation, le client réutilise ce payload au lieu de re-fetcher. La clé est ce qui permet la réconciliation — deux appels avec la même clé partagent la même donnée (on s'en sert sur cette plateforme : useCourse est appelé par la page sommaire ET la page leçon, un seul fetch).

Les règles d'usage

• useFetch(url) = useAsyncData + $fetch packagés — pour appeler une URL directement ;
• $fetch nu : pour les actions (POST au clic, mutations) — pas de double-rendu à gérer puisque déclenché côté client ;
• le retour est riche : { data, status, error, refresh } — refresh() re-exécute (après une mutation, par exemple) ;
• le piège n°1 : appeler useAsyncData dans une fonction ou un handler — comme tout composable, il vit au setup. Pour un fetch au clic : $fetch ;
• le piège n°2 : oublier await — la page se rend avant les données (data vaut null au premier rendu serveur).

Où mettre la logique : le composable de données

Le pattern de cette plateforme (et du projet copilot) : envelopper useAsyncData dans un composable métier (useCourse(slug), useCatalog()) — la page ne connaît ni la clé, ni la source (Content, API, BFF), juste le contrat. Changer la source de données = changer le composable, zéro page touchée.