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

> Charger des données distantes ou internes avec apiFetch, gérer le chargement, les erreurs, et éviter les appels redondants dans l'éditeur de blocs.

- Auteur : Clément Hadrot
- Publié le : 2021-03-19
- Mis à jour le : 2021-03-19
- Catégorie : Blocs Gutenberg
- URL : https://wpmoderne.dev.wordpress-developpement.fr/blocs/apifetch-bloc-donnees-rest-editeur/

## L’essentiel

- apiFetch ajoute automatiquement le nonce et le bon en-tête d'authentification
- Un état de chargement explicite évite un aperçu vide trompeur
- Une erreur réseau doit s'afficher, jamais échouer silencieusement

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

> L'essentiel à retenir : apiFetch ajoute automatiquement le nonce et le bon en-tête d'authentification ; Un état de chargement explicite évite un aperçu vide trompeur ; Une erreur réseau doit s'afficher, jamais échouer silencieusement

```
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.