apiFetch dans un bloc : afficher des données REST directement dans l’éditeur

Un bloc « derniers avis clients » qui reste désespérément vide pendant deux secondes avant d’afficher son contenu, sans le moindre indicateur visuel : c’est l’expérience que subissent trop souvent les utilisateurs de blocs qui consomment des données distantes sans gérer correctement leur état de chargement. Le paquet @wordpress/api-fetch résout la partie technique de la requête, mais la gestion de l’état reste entièrement à la charge du développeur.

Pourquoi apiFetch plutôt que fetch natif

apiFetch encapsule l’API fetch native du navigateur en y ajoutant automatiquement ce que WordPress exige pour une requête authentifiée vers son API REST : l’en-tête X-WP-Nonce, la base d’URL correcte de l’installation, et un système de middleware qui permet, entre autres, de gérer les erreurs de manière homogène sur tout le site.

import apiFetch from '@wordpress/api-fetch';

apiFetch( { path: '/wp/v2/posts?per_page=5' } ).then( ( posts ) => {
	console.log( posts );
} );

Utiliser fetch natif directement fonctionnerait techniquement, mais obligerait à reproduire manuellement la gestion du nonce et exposerait le bloc à des erreurs 401 dès que la session de l’utilisateur expire en cours d’édition.

Charger les données au montage du bloc

import { useState, useEffect } from '@wordpress/element';
import apiFetch from '@wordpress/api-fetch';
import { Spinner, Notice } from '@wordpress/components';

export default function Edit() {
	const [ avis, setAvis ] = useState( null );
	const [ erreur, setErreur ] = useState( null );

	useEffect( () => {
		apiFetch( { path: '/mon-projet/v1/avis?per_page=5' } )
			.then( setAvis )
			.catch( ( err ) => setErreur( err.message ) );
	}, [] );

	if ( erreur ) {
		return <Notice status="error" isDismissible={ false }>{ erreur }</Notice>;
	}
	if ( avis === null ) {
		return <Spinner />;
	}
	return (
		<ul>
			{ avis.map( ( a ) => <li key={ a.id }>{ a.title }</li> ) }
		</ul>
	);
}

Trois états distincts, et trois seuls : chargement (avis === null), erreur, et données prêtes. Ce découpage simple évite le bloc « vide muet » qui laisse l’auteur se demander si son bloc fonctionne réellement.

Éviter les requêtes en rafale

Un tableau de dépendances vide ([]) sur useEffect garantit que l’appel n’a lieu qu’une fois par montage du composant. Le piège classique survient quand la requête dépend d’un attribut du bloc (un identifiant de catégorie, par exemple) : sans dépendance correctement déclarée, soit la requête ne se relance jamais quand l’attribut change, soit elle se relance à chaque rendu si le tableau de dépendances est omis.

useEffect( () => {
	apiFetch( { path: `/mon-projet/v1/avis?categorie=${ categorieId }` } )
		.then( setAvis )
		.catch( ( err ) => setErreur( err.message ) );
}, [ categorieId ] );

Utiliser core-data plutôt que apiFetch quand c’est possible

Pour les entités natives de WordPress (articles, pages, types personnalisés déjà exposés dans l’API REST), le store core combiné à useSelect et à un sélecteur comme getEntityRecords gère lui-même le cache, le partage entre blocs et la résolution des requêtes — ce qui évite de réimplémenter manuellement ce que @wordpress/data propose déjà pour ces cas précis. apiFetch garde tout son intérêt pour des points d’accès personnalisés, hors du périmètre de core.

• Point d’accès natif WordPress (articles, taxonomies) : privilégier core et ses sélecteurs.
• Point d’accès personnalisé d’une extension : apiFetch reste l’outil adapté.
• Service tiers externe au site : apiFetch fonctionne aussi, à condition de passer { url: '...' } plutôt que { path: '...' }, ce dernier étant réservé aux chemins relatifs à l’API REST du site.

Un bloc qui interroge une API à chaque frappe de clavier dans l’inspecteur, sans le moindre debounce, finit toujours par saturer les journaux d’erreurs du serveur en production.

En résumé

apiFetch retire la complexité de l’authentification des requêtes REST côté éditeur, mais ne dispense pas de gérer explicitement les trois états d’une requête asynchrone. Un bloc qui affiche un chargeur, une erreur lisible et des données à jour donne une bien meilleure impression de fiabilité qu’un bloc techniquement fonctionnel mais silencieux sur son propre état.