# WPGraphQL Content Blocks : récupérer les blocs Gutenberg typés en GraphQL

> L'extension qui expose chaque bloc Gutenberg comme un type GraphQL distinct, attributs compris, pour un rendu front fidèle sans parsing manuel.

- Auteur : Clément Hadrot
- Publié le : 2024-03-22
- Mis à jour le : 2024-03-22
- Catégorie : Headless & API
- URL : https://wpmoderne.dev.wordpress-developpement.fr/headless/wpgraphql-content-blocks-blocs-gutenberg-typed-graphql/

## L’essentiel

- Chaque bloc devient un type GraphQL avec ses attributs typés
- Fini le parsing manuel du contenu HTML brut
- Le rendu front suit exactement la structure de l'éditeur

Un magazine en ligne construisait ses articles entièrement avec l'éditeur de blocs natif : citations, galeries, tableaux, colonnes, blocs personnalisés pour les fiches produits chroniquées. Le premier réflexe côté front avait été de récupérer le contenu rendu en HTML via `content { rendered }` et de le parser à la main pour retrouver la structure. Fragile, verbeux, et incapable de distinguer proprement un bloc personnalisé d'un simple paragraphe.

WPGraphQL Content Blocks change complètement l'approche : plutôt que de renvoyer du HTML à interpréter, l'extension expose directement l'arbre des blocs de l'éditeur, chacun avec son type GraphQL propre et ses attributs correctement typés.

## Ce que l'extension change dans le schéma

Une fois activée, chaque type de contenu qui utilise l'éditeur de blocs gagne un champ `editorBlocks`, qui renvoie une liste de blocs typés plutôt qu'une chaîne HTML. Un bloc citation natif ressort par exemple sous forme d'un type `CoreQuote` avec ses propriétés de citation et d'attribution directement accessibles.

```
{
  post(id: "chronique-du-mois", idType: SLUG) {
    editorBlocks {
      __typename
      ... on CoreParagraph { content }
      ... on CoreQuote { value citation }
      ... on CoreGallery { innerBlocks { ... on CoreImage { url alt } } }
    }
  }
}
```

## Les blocs personnalisés suivent la même logique

Un bloc personnalisé enregistré côté PHP avec `register_block_type` et ses attributs déclarés dans son `block.json` ressort lui aussi comme un type GraphQL dédié, à condition que ses attributs respectent des types simples reconnus par l'extension (chaîne, nombre, booléen). Pour le bloc « fiche produit chroniqué » de ce projet, chaque attribut (nom du produit, note, lien d'achat) est devenu directement interrogeable, sans aucune extraction manuelle depuis un contenu HTML.

> L'essentiel à retenir : Chaque bloc devient un type GraphQL avec ses attributs typés ; Fini le parsing manuel du contenu HTML brut ; Le rendu front suit exactement la structure de l'éditeur

## Rendre les blocs côté front

Comme pour un champ flexible ACF, on construit un registre qui associe chaque `__typename` de bloc à un composant front dédié :

```
const registreBlocs = {
  CoreParagraph: BlocParagraphe,
  CoreQuote: BlocCitation,
  CoreGallery: BlocGalerie,
  AcmeFicheProduit: BlocFicheProduit,
};

function ArticleComplet({ blocs }) {
  return blocs.map((bloc, i) => {
    const Composant = registreBlocs[bloc.__typename];
    return Composant ? <Composant key={i} {...bloc} /> : null;
  });
}
```

Les blocs imbriqués (une colonne contenant elle-même des paragraphes, une galerie contenant des images) exposent leurs enfants via un champ `innerBlocks`, qu'il faut alors traiter récursivement avec le même registre.

## Ce qu'on gagne par rapport au HTML brut

- Plus aucune expression régulière pour retrouver un attribut caché dans un commentaire de bloc HTML.
- Un contrôle total sur le rendu de chaque type de bloc côté front, sans dépendre du CSS du thème d'origine.
- Une détection immédiate quand un bloc inconnu apparaît dans le contenu, plutôt qu'un rendu silencieusement incorrect.

## Ordonner et filtrer les blocs avant le rendu

Le tableau `editorBlocks` respecte l'ordre exact de composition dans l'éditeur, ce qui évite tout retri côté front. Une pratique utile sur ce projet a consisté à filtrer, avant le rendu, les blocs purement décoratifs sans équivalent utile côté front (un simple espaceur, par exemple), plutôt que de laisser le registre de composants renvoyer silencieusement `null` pour chacun d'eux : le filtrage explicite en amont rend le composant de rendu plus lisible pour quiconque reprend le projet plus tard.

## Une limite à connaître

Tous les blocs tiers ne déclarent pas proprement leurs attributs dans un `block.json` conforme, en particulier les blocs plus anciens écrits avant la généralisation de ce format. Dans ce cas, l'extension retombe sur une représentation générique moins exploitable, et il faut parfois réécrire soi-même la déclaration du bloc concerné pour profiter pleinement du typage.

> Un bloc personnalisé bien déclaré dès le départ, avec des attributs typés dans son `block.json`, s'exporte proprement en GraphQL sans aucun travail supplémentaire : ça vaut la peine de soigner cette déclaration dès la création du bloc.

## Ce qu'on retient

WPGraphQL Content Blocks rapproche le front de ce que l'éditeur voit réellement, bloc par bloc, plutôt que d'un rendu HTML à réinterpréter. Pour un site qui exploite largement l'éditeur natif avec des blocs personnalisés, c'est probablement l'approche la plus fidèle et la plus maintenable pour reconstituer la mise en page côté découplé.