Next.js domine largement les tutoriels headless WordPress trouvés en ligne, mais l’écosystème Vue.js dispose de son propre framework de référence pour la génération de sites statiques et le rendu hybride : Nuxt. Pour une équipe déjà investie dans Vue.js, ou pour un développeur qui préfère sa syntaxe de composants à celle de React, Nuxt offre une expérience tout aussi mature pour bâtir un frontend headless.
Ce guide construit un blog headless simple avec Nuxt et l’API REST WordPress, en s’appuyant sur les mécanismes de récupération de données et de génération statique propres à l’écosystème Vue.
Structure d’un projet Nuxt
Un projet Nuxt organise ses vues dans le dossier pages/, avec un système de routage basé sur les fichiers, comparable à celui de Next.js. Une page dynamique se déclare avec un préfixe underscore : pages/articles/_slug.vue correspond à une route du type /articles/mon-article.
Récupérer les données avec asyncData
Nuxt propose la méthode spéciale asyncData, exécutée côté serveur (ou au build en mode statique) avant le rendu du composant. Elle fusionne directement son résultat avec les données du composant :
<template>
<ul>
<li v-for="article in articles" :key="article.id">
<nuxt-link :to="`/articles/${article.slug}`">
{{ article.title.rendered }}
</nuxt-link>
</li>
</ul>
</template>
<script>
export default {
async asyncData( { $http } ) {
const articles = await $http.$get(
'https://exemple.fr/wp-json/wp/v2/posts?_embed&per_page=10'
);
return { articles };
},
};
</script>Le module @nuxt/http simplifie ces appels, mais une simple fonction fetch native fonctionne tout aussi bien si vous préférez limiter les dépendances du projet.
Les pages dynamiques par slug
Pour la page de détail d’un article, le fichier pages/articles/_slug.vue récupère le paramètre de route via le contexte fourni à asyncData :
<script>
export default {
async asyncData( { params, error } ) {
const reponse = await fetch(
`https://exemple.fr/wp-json/wp/v2/posts?slug=${params.slug}&_embed`
);
const [ article ] = await reponse.json();
if ( ! article ) {
return error( { statusCode: 404, message: 'Article introuvable' } );
}
return { article };
},
};
</script>
<template>
<article>
<h1>{{ article.title.rendered }}</h1>
<div v-html="article.content.rendered"></div>
</article>
</template>La directive v-html joue ici le même rôle que dangerouslySetInnerHTML côté React : elle injecte le HTML brut renvoyé par WordPress. Comme dans l’écosystème React, cela ne pose pas de problème de sécurité tant que la source du contenu, ici votre propre WordPress, reste de confiance.
Générer un site entièrement statique
Pour produire un export statique complet, prêt à héberger sur un CDN, Nuxt propose la commande nuxt generate. En mode statique, Nuxt doit connaître à l’avance la liste des routes dynamiques à générer, via la propriété generate.routes dans nuxt.config.js :
// nuxt.config.js
export default {
target: 'static',
generate: {
async routes() {
const reponse = await fetch(
'https://exemple.fr/wp-json/wp/v2/posts?_fields=slug&per_page=100'
);
const articles = await reponse.json();
return articles.map( ( article ) => `/articles/${ article.slug }` );
},
},
};Next.js ou Nuxt : quelle différence concrète ?
Sur le fond, les deux frameworks résolvent le même problème avec une philosophie très proche : récupération de données avant le rendu, génération statique ou hybride, routage basé sur les fichiers. Le choix dépend surtout de l’écosystème déjà maîtrisé par l’équipe.
- Une équipe habituée à React ira naturellement vers Next.js, avec un écosystème de composants et d’outils plus large en 2022
- Une équipe habituée à Vue.js retrouvera dans Nuxt une syntaxe de templates plus proche du HTML classique, souvent perçue comme plus accessible pour des profils moins expérimentés en JavaScript
- Les deux disposent d’un mécanisme de régénération incrémentale, bien que celui de Next.js (ISR) soit historiquement plus documenté pour un usage headless WordPress
Le choix du framework compte moins que la rigueur de l’architecture de récupération des données. Sur nos projets, nous isolons systématiquement les appels API dans des modules réutilisables, quel que soit le framework choisi : cela facilite une éventuelle bascule ultérieure vers WPGraphQL.
En résumé
Nuxt offre une alternative solide et mature à Next.js pour bâtir un frontend headless WordPress, avec une expérience développeur pensée pour l’écosystème Vue.js. La logique reste la même : récupérer les données avant le rendu, générer les pages dynamiques à partir des slugs disponibles, et structurer le code pour rester adaptable si la source de données venait à évoluer vers GraphQL.
