# useEntityProp : lire et écrire des métadonnées d’article depuis un bloc

> Enregistrer un meta avec show_in_rest et le manipuler depuis un bloc grâce à useEntityProp, sans jamais stocker cette donnée dans le contenu de l'article.

- Auteur : Clément Hadrot
- Publié le : 2021-04-15
- Mis à jour le : 2021-04-15
- Catégorie : Blocs Gutenberg
- URL : https://wpmoderne.dev.wordpress-developpement.fr/blocs/useentityprop-metadonnees-article-bloc/

## L’essentiel

- Un meta n'est pas un attribut de bloc, il vit sur l'article
- show_in_rest est obligatoire pour qu'un meta soit lisible côté éditeur
- useEntityProp synchronise automatiquement avec le bouton Publier

Un champ « durée de lecture estimée » qu'un client voulait pouvoir corriger manuellement, affiché dans un bloc en haut d'article : la mauvaise solution consiste à stocker cette valeur comme un attribut du bloc. La bonne solution consiste à en faire une métadonnée d'article, lue et modifiée depuis le bloc via `useEntityProp`, sans qu'elle ne transite jamais par le contenu HTML sauvegardé.

## Pourquoi un meta plutôt qu'un attribut de bloc

Un attribut de bloc vit dans le contenu de l'article, sérialisé sous forme de commentaire HTML au moment de la sauvegarde. Une métadonnée (`post meta`) vit dans une table séparée de la base de données, indépendante du contenu. Cette distinction compte dès qu'une donnée doit rester accessible même si le bloc qui l'affiche est supprimé de l'article, ou doit être interrogeable directement en base ou via une requête `WP_Query` avec `meta_query` — ce qu'un attribut de bloc ne permet pas.

## Étape 1 : enregistrer le meta côté PHP

```
<?php
add_action( 'init', function () {
	register_post_meta( 'post', 'duree_lecture', [
		'type'         => 'integer',
		'single'       => true,
		'show_in_rest' => true,
		'default'      => 0,
	] );
} );
```

`show_in_rest` à `true` est la condition indispensable : sans cette clé, le meta reste invisible depuis l'API REST, donc invisible depuis l'éditeur de blocs, qui s'appuie entièrement sur cette API pour lire et écrire les données de l'article.

## Étape 2 : déclarer que le bloc utilise les métadonnées

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

Cette déclaration dans `block.json` donne accès à l'identifiant et au type de l'article courant, nécessaires pour que `useEntityProp` sache sur quelle entité lire et écrire.

## Étape 3 : lire et écrire avec useEntityProp

> L'essentiel à retenir : Un meta n'est pas un attribut de bloc, il vit sur l'article ; show_in_rest est obligatoire pour qu'un meta soit lisible côté éditeur ; useEntityProp synchronise automatiquement avec le bouton Publier

```
import { useEntityProp } from '@wordpress/core-data';
import { TextControl } from '@wordpress/components';

export default function Edit( { context } ) {
	const [ meta, setMeta ] = useEntityProp(
		'postType',
		context.postType,
		'meta'
	);

	return (
		<TextControl
			label="Durée de lecture (minutes)"
			type="number"
			value={ meta.duree_lecture }
			onChange={ ( valeur ) =>
				setMeta( { ...meta, duree_lecture: Number( valeur ) } )
			}
		/>
	);
}
```

`useEntityProp` renvoie un couple valeur/setter, sur le modèle de `useState`, mais branché directement sur l'entité REST de l'article. Toute modification via `setMeta` marque automatiquement l'article comme modifié, ce qui active le bouton « Mettre à jour » sans code supplémentaire — c'est ce comportement qui distingue ce hook d'un simple appel à `apiFetch` manuel.

## Un piège fréquent : écraser les autres clés du meta

La ligne `{ ...meta, duree_lecture: Number( valeur ) }` n'est pas cosmétique : `meta` regroupe toutes les métadonnées exposées en REST pour l'article, pas seulement celle manipulée par ce bloc. Écrire directement `setMeta( { duree_lecture: valeur } )` écraserait silencieusement toutes les autres métadonnées déjà enregistrées par d'autres blocs ou extensions.

## Où s'arrête ce hook

- Il ne fonctionne que sur des entités exposées en REST (articles, pages, types personnalisés avec `show_in_rest`), pas sur des options globales du site.
- Il ne remplace pas un champ ACF ou un champ personnalisé complexe avec une logique de validation métier poussée, qui reste plus à l'aise côté PHP.
- Il ne gère pas la révision ni l'historique du meta : contrairement au contenu de l'article, les métadonnées ne sont pas versionnées par le système de révisions natif.

> Un champ qui doit rester interrogeable indépendamment du contenu de l'article — une note interne, une date d'expiration, un identifiant externe — appartient presque toujours à un meta, jamais à un attribut de bloc.

## En résumé

`useEntityProp` offre une synchronisation propre entre un champ affiché dans un bloc et une métadonnée réelle de l'article, à condition d'avoir correctement exposé cette métadonnée en REST côté PHP.