# usesContext dans block.json : consommer le contexte d’un parent

> Trois blocs enfants recopiaient la même couleur en attribut dupliqué. Un seul champ de block.json a suffi à supprimer cette duplication.

- Auteur : Clément Hadrot
- Publié le : 2021-05-18
- Mis à jour le : 2021-05-18
- Catégorie : Blocs Gutenberg
- URL : https://wpmoderne.dev.wordpress-developpement.fr/blocs/usescontext-block-json-contexte-parent/

## L’essentiel

- usesContext liste les clés de contexte à recevoir
- Le contexte arrive en lecture seule dans edit et save
- providesContext reste défini côté bloc parent

Un bloc « Grille de témoignages » avait été conçu avec un bloc parent définissant une couleur d'accent globale, et des blocs enfants (chacun représentant un témoignage individuel) censés hériter de cette couleur pour teinter leur bordure. La première version du développeur stockait cette couleur en tant qu'attribut dupliqué sur chaque bloc enfant, synchronisé tant bien que mal par un effet JavaScript à chaque changement côté parent. Le résultat fonctionnait, mais avec un temps de latence visible et des incohérences dès que deux enfants étaient modifiés rapidement l'un après l'autre.

La bonne solution, disponible depuis longtemps mais souvent ignorée, s'appelle le contexte de bloc. Plutôt que de dupliquer une donnée dans les attributs de chaque enfant, le bloc parent la « fournit » une seule fois via `providesContext`, et chaque enfant intéressé la « consomme » simplement en la déclarant dans `usesContext`.

## Déclarer la consommation côté enfant

Dans `block.json` du bloc enfant, la propriété `usesContext` liste les clés de contexte auxquelles le bloc souhaite avoir accès. Ces clés doivent correspondre exactement à celles définies dans `providesContext` du bloc parent, généralement préfixées par l'espace de nom de l'extension pour éviter toute collision avec un contexte fourni par un autre bloc.

```
{
  "name": "mon-agence/temoignage-item",
  "usesContext": [ "mon-agence/couleur-accent" ]
}
```

## Recevoir le contexte dans edit et save

Une fois déclaré, le contexte arrive automatiquement comme une prop nommée `context` dans la fonction `edit` du bloc enfant, un objet contenant uniquement les clés effectivement déclarées dans `usesContext`, jamais l'ensemble du contexte disponible dans l'arbre.

```
export default function Edit( { context } ) {
    const couleur = context[ 'mon-agence/couleur-accent' ] ?? '#000000';
    const blockProps = useBlockProps( {
        style: { borderColor: couleur },
    } );
    return <div { ...blockProps }>Témoignage</div>;
}
```

Le contexte est aussi disponible dans la fonction `save` si le bloc enfant en a besoin pour générer son balisage statique, avec la même limitation : uniquement les clés déclarées.

## Ce que fait le parent, en miroir

> L'essentiel à retenir : usesContext liste les clés de contexte à recevoir ; Le contexte arrive en lecture seule dans edit et save ; providesContext reste défini côté bloc parent

Côté parent, la propriété `providesContext` associe chaque clé de contexte à un attribut du bloc parent lui-même. Aucun mécanisme de synchronisation manuelle n'est nécessaire : dès que l'attribut change côté parent, tous les enfants qui consomment cette clé de contexte reçoivent la nouvelle valeur automatiquement, via le rendu React normal.

```
{
  "name": "mon-agence/grille-temoignages",
  "attributes": {
    "couleurAccent": { "type": "string", "default": "#2563eb" }
  },
  "providesContext": {
    "mon-agence/couleur-accent": "couleurAccent"
  }
}
```

## Une limite à connaître : la hiérarchie stricte

Le contexte de bloc ne circule que le long de la hiérarchie parent-enfant directe, telle que représentée dans l'arbre de blocs de l'éditeur. Un bloc enfant ne reçoit un contexte que si l'un de ses ancêtres directs le fournit ; il ne peut pas récupérer un contexte fourni par un bloc « cousin » situé ailleurs dans l'arbre, même visuellement proche sur la page.

- Le contexte traverse plusieurs niveaux d'imbrication sans déclaration intermédiaire nécessaire.
- Un bloc peut consommer plusieurs clés de contexte venant de différents ancêtres à la fois.
- Le contexte n'est jamais accessible en dehors de l'arbre de blocs, contrairement à une donnée de store global.

## Contexte contre attribut dupliqué : le bon critère

Le critère de décision reste simple : si une donnée doit rester identique entre un parent et tous ses enfants, sans exception ni personnalisation possible au niveau de l'enfant, le contexte est presque toujours préférable à un attribut dupliqué. Si, en revanche, chaque enfant doit pouvoir personnaliser librement cette valeur au-delà de l'héritage initial, un attribut propre à l'enfant, éventuellement pré-rempli à partir du contexte au moment de l'insertion, reste plus adapté.

> Le contexte de bloc résout un problème précis : la synchronisation descendante d'une donnée dans un arbre. Il ne remplace ni un store de données pour des besoins transversaux, ni des attributs pour des personnalisations réellement indépendantes.

## Bilan

Après remplacement de la synchronisation manuelle par le contexte natif sur le projet de grille de témoignages, le comportement est devenu instantané et sans incohérence, pour une quantité de code très inférieure à l'effet JavaScript qu'il a remplacé. usesContext et providesContext restent sous-utilisés par méconnaissance plus que par complexité réelle : la mécanique, une fois comprise, tient en quelques lignes de déclaration dans block.json.