# Block context : partager des données d’un bloc parent vers ses enfants

> providesContext et usesContext dans block.json : le mécanisme discret qui fait fonctionner la Query Loop, et comment un bloc parent peut configurer ses enfants.

- Auteur : Clément Hadrot
- Publié le : 2021-05-20
- Mis à jour le : 2021-05-20
- Catégorie : Blocs Gutenberg
- URL : https://wpmoderne.dev.wordpress-developpement.fr/blocs/block-context-partager-donnees-parent-enfants/

## L’essentiel

- providesContext expose un attribut du parent aux blocs descendants
- usesContext ne donne accès qu'en lecture, jamais en écriture
- La Query Loop repose entièrement sur ce mécanisme

Comment le bloc Titre de requête, inséré dans une Query Loop, sait-il quel article afficher sans qu'aucun attribut ne le lui indique explicitement ? La réponse tient dans un mécanisme peu documenté par ses cas d'usage concrets : le block context, qui permet à un bloc parent de partager certaines de ses données avec tous ses blocs descendants, sans passer par des props manuelles à chaque niveau.

## Le principe, en deux déclarations

Un bloc parent déclare, dans son `block.json`, les attributs qu'il rend disponibles via `providesContext`. Un bloc enfant déclare, toujours dans son `block.json`, les clés de contexte qu'il souhaite lire via `usesContext`. Aucune prop React explicite ne transite manuellement entre les deux : Gutenberg se charge de la propagation à travers toute la hiérarchie d'`InnerBlocks`, même sur plusieurs niveaux d'imbrication.

```
// block.json du bloc parent
{
	"name": "mon-projet/galerie-filtrable",
	"attributes": {
		"categorieActive": { "type": "string", "default": "" }
	},
	"providesContext": {
		"mon-projet/categorieActive": "categorieActive"
	}
}
```

```
// block.json du bloc enfant
{
	"name": "mon-projet/vignette-produit",
	"usesContext": [ "mon-projet/categorieActive" ]
}
```

## Lire le contexte côté edit

> L'essentiel à retenir : providesContext expose un attribut du parent aux blocs descendants ; usesContext ne donne accès qu'en lecture, jamais en écriture ; La Query Loop repose entièrement sur ce mécanisme

```
export default function Edit( { context } ) {
	const categorie = context[ 'mon-projet/categorieActive' ];

	return <p>Filtré sur : { categorie || 'toutes les catégories' }</p>;
}
```

La prop `context` arrive automatiquement dans la fonction `Edit` dès que le bloc a déclaré `usesContext` pour la clé correspondante. Ce contexte est en lecture seule : un bloc enfant ne peut pas modifier la valeur fournie par le parent, il ne fait que la consulter pour adapter son propre comportement.

## Le cas de la Query Loop

Le bloc Boucle de requête (Query Loop), introduit avec l'éditeur de site, illustre le mécanisme à grande échelle : il fournit un contexte `postId` et `postType` à chaque itération de sa boucle, que ses blocs descendants (Titre de requête, Extrait, Image à la une) consomment via `usesContext` pour savoir de quel article afficher les données, sans jamais recevoir cet identifiant en dur dans leurs propres attributs.

```
{
	"usesContext": [ "postId", "postType" ]
}
```

C'est ce même mécanisme, combiné à `useEntityProp` vu par ailleurs, qui permet à un bloc générique comme Titre de requête de fonctionner identiquement, qu'il soit placé dans une boucle d'articles de blog ou une boucle de produits d'un type de contenu personnalisé.

## Construire un bloc parent qui configure ses enfants

Un bloc « onglets » qui doit indiquer à chacun de ses panneaux enfants quel onglet est actuellement actif illustre un cas d'usage hors du cœur de WordPress :

```
// parent : onglets.js (block.json)
"providesContext": {
	"mon-projet/ongletActif": "ongletActif"
}

// enfant : panneau.js (block.json)
"usesContext": [ "mon-projet/ongletActif" ]
```

Le bloc panneau lit alors `context[ 'mon-projet/ongletActif' ]` pour décider s'il doit s'afficher ou rester masqué, sans que le bloc parent n'ait besoin de connaître individuellement chacun de ses enfants ni de leur transmettre une prop bloc par bloc.

## Limites à connaître

- Le contexte ne traverse pas les frontières de `ServerSideRender` : un bloc rendu côté PHP au moment de l'aperçu ne reçoit pas automatiquement ce contexte côté client.
- Seuls les attributs explicitement listés dans `providesContext` sont exposés ; le reste des attributs du parent reste invisible aux enfants.
- Un espace de nom clair sur les clés de contexte (`mon-projet/...`) évite les collisions avec un contexte de même nom fourni par un autre bloc ou par le cœur de WordPress.

> Avant d'imaginer un système de contexte personnalisé, il vaut la peine de vérifier si le besoin ne rejoint pas un cas déjà couvert par la Query Loop : réinventer ce mécanisme prend nettement plus de temps que de le réutiliser.

## En résumé

Le block context reste l'un des mécanismes les plus élégants de Gutenberg pour construire des blocs composés dont les enfants s'adaptent automatiquement au parent, sans props manuelles ni store global superflu. Il complète, sans le remplacer, le sujet plus large d'InnerBlocks, qui gère la composition elle-même.