La différence qu’un troisième niveau de contexte imbriqué fait dans InnerBlocks

Un contexte de bloc qui fonctionne parfaitement entre un parent et un enfant direct peut disparaître dès qu’on ajoute un petit-enfant. Ce constat surprend souvent les développeurs qui construisent des blocs composés profondément, avec une structure du type bloc racine, puis section, puis carte individuelle. Le contexte à un seul niveau, lui, est déjà bien documenté ; ce billet se concentre sur ce qui change concrètement à partir du troisième niveau.

Le scénario typique ressemble à ceci : un bloc galerie-produits fournit un contexte produitCategorie via providesContext, un bloc groupe-produit l’utilise correctement en second niveau, mais un bloc etiquette-produit, imbriqué dans le groupe, reçoit une valeur vide alors qu’il déclare pourtant usesContext avec la même clé.

Comment le contexte circule réellement dans l’arbre de blocs

Le mécanisme de contexte de WordPress fonctionne par propagation descendante stricte : un bloc parent qui déclare providesContext dans son block.json met une valeur à disposition de tous ses descendants InnerBlocks, à condition que chacun d’eux la demande explicitement via sa propre entrée usesContext. Cette propagation n’est pas automatique de niveau en niveau : elle passe par le rendu React de chaque bloc intermédiaire.

C’est précisément là que se situe le piège du troisième niveau. Si le bloc intermédiaire, celui du deuxième niveau, ne déclare pas usesContext pour la clé en question, ou s’il la déclare mais ne relaie pas correctement ses propres InnerBlocks, le troisième niveau ne reçoit tout simplement rien, même si le premier niveau fournit bien la donnée.

Reproduire le problème avec une déclaration minimale

Voici une déclaration block.json qui illustre la source exacte du problème sur le bloc intermédiaire :

{
  "name": "monplugin/groupe-produit",
  "providesContext": {
    "monplugin/produitCategorie": "categorieActive"
  }
}

Ce bloc intermédiaire redéclare une clé de contexte sous son propre espace de nom, sans jamais avoir déclaré usesContext pour lire la valeur venue du parent. Résultat : il fournit bien un contexte à ses propres enfants, mais ce contexte repart d’une valeur locale, jamais alimentée par le parent réel.

La correction : relayer explicitement à chaque niveau

La correction consiste à faire lire, puis relire, le bloc intermédiaire avant qu’il ne fournisse à son tour la valeur à ses enfants :

{
  "name": "monplugin/groupe-produit",
  "usesContext": [ "monplugin/produitCategorie" ],
  "providesContext": {
    "monplugin/produitCategorie": "monplugin/produitCategorie"
  }
}

Côté composant edit, la lecture explicite se fait ainsi :

function Edit( { context } ) {
	const categorie = context[ 'monplugin/produitCategorie' ];
	return <InnerBlocks />;
}

Un piège aggravé par les blocs génériques

La difficulté grandit encore quand le bloc du deuxième niveau est un bloc générique du cœur, comme le bloc Groupe, qui ne relaie évidemment aucun contexte personnalisé de votre extension. Dans ce cas, il n’existe aucun moyen de faire transiter le contexte à travers ce niveau intermédiaire sans y insérer un bloc dédié, capable de lire et de retransmettre la valeur.

• Vérifier systématiquement que chaque bloc intermédiaire de la hiérarchie déclare usesContext pour la clé recherchée.
• Éviter d’insérer un bloc générique du cœur entre un fournisseur de contexte et son consommateur final.
• Nommer les clés de contexte avec l’espace de nom complet de l’extension, pour éviter toute collision avec un autre plugin.

Sur un arbre de blocs composés, mieux vaut tracer sur papier, avant d’écrire le moindre code, la chaîne complète des providesContext et usesContext attendue à chaque niveau : c’est souvent le seul moyen de repérer le maillon manquant.

En résumé

Le contexte de bloc ne traverse jamais un niveau qui ne le demande pas explicitement, et cette règle simple devient difficile à appliquer mentalement dès qu’un troisième niveau d’InnerBlocks s’ajoute à la structure. La solution ne relève d’aucune astuce cachée : elle demande de vérifier, niveau par niveau, que chaque bloc intermédiaire relaie bien ce qu’il reçoit avant de le fournir à son tour à ses propres enfants.