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

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

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.