Face à face : d’un côté withSelect et withDispatch, les composants d’ordre supérieur historiques du paquet @wordpress/data, présents depuis les premières versions de l’éditeur de blocs. De l’autre, useSelect et useDispatch, deux hooks React qui remplissent le même rôle avec une syntaxe plus courte. Pour un bloc qui démarre aujourd’hui, la question mérite d’être tranchée avant d’écrire la première ligne, plutôt que de mélanger les deux styles au fil des mises à jour.
Les deux approches restent pleinement supportées dans la version actuelle de Gutenberg : il ne s’agit pas d’un choix entre une API dépréciée et une API moderne, mais bien de deux conventions d’écriture qui coexistent, chacune avec ses avantages selon le contexte du bloc.
Ce que fait withSelect concrètement
withSelect enveloppe un composant et lui injecte des props calculées à partir du magasin de données WordPress, en se ré-exécutant automatiquement quand les données observées changent :
import { withSelect } from '@wordpress/data';
const EditAvecSelect = withSelect( ( select, ownProps ) => {
const { getEntityRecord } = select( 'core' );
return {
auteur: getEntityRecord( 'root', 'user', ownProps.attributes.idAuteur ),
};
} )( ComposantEdit );
Le composant reçoit une prop auteur déjà résolue, sans avoir à gérer lui-même l’abonnement au magasin de données.
Le même résultat avec useSelect
Le hook useSelect, plus récent, obtient un résultat identique directement à l’intérieur du composant fonctionnel, sans composant enveloppant supplémentaire :
import { useSelect } from '@wordpress/data';
function ComposantEdit( { attributes } ) {
const auteur = useSelect(
( select ) => select( 'core' ).getEntityRecord( 'root', 'user', attributes.idAuteur ),
[ attributes.idAuteur ]
);
return <p>{ auteur ? auteur.name : '…' }</p>;
}
La logique est identique, mais elle vit directement dans le composant, ce qui évite d’exporter deux versions du même composant (l’une brute, l’autre enveloppée) et facilite la lecture d’un bloc qui ne fait que quelques dizaines de lignes.
Où withDispatch garde un avantage
withDispatch permet d’injecter des fonctions d’action toutes prêtes, ce qui simplifie parfois la relecture d’un composant qui ne fait qu’appeler ces fonctions dans ses gestionnaires d’événements :
const EditAvecDispatch = withDispatch( ( dispatch ) => ( {
mettreAJourTitre( titre ) {
dispatch( 'core/editor' ).editPost( { title: titre } );
},
} ) )( ComposantEdit );
Avec useDispatch, il faut récupérer l’objet de dispatch puis appeler la méthode voulue à chaque usage, ce qui rallonge légèrement le code des gestionnaires d’événements mais reste tout aussi lisible pour qui connaît déjà les hooks.
Tableau comparatif
| Critère | withSelect / withDispatch | useSelect / useDispatch |
|---|---|---|
| Niveau d’imbrication | Un composant enveloppant supplémentaire | Aucun, tout reste dans le composant |
| Lisibilité sur un bloc simple | Correcte | Meilleure, moins de code de câblage |
| Compatibilité avec compose() | Native, conçus pour ça | Possible mais moins naturelle |
| Réexécution sur changement de données | Automatique | Automatique, via le tableau de dépendances |
| Ancienneté dans l’écosystème | Présents depuis les débuts de l’éditeur | Plus récents dans le paquet |
Ce qui doit vraiment guider le choix
- Sur un projet qui compte déjà plusieurs blocs écrits avec des HOC, garder la même convention limite la charge mentale d’un développeur qui passe de l’un à l’autre.
- Sur un bloc neuf, sans historique à respecter, les hooks réduisent le nombre de lignes de câblage.
- Un bloc qui combine plusieurs HOC (via
compose()) reste parfois plus lisible avecwithSelect/withDispatch, tous deux pensés pour cette composition. - Aucun message de dépréciation n’accompagne aujourd’hui l’usage des HOC : le choix n’a pas de date de péremption connue à ce stade.
Sur nos projets, la règle est simple : on ne migre pas un bloc existant juste pour suivre la mode des hooks. On choisit les hooks sur tout bloc neuf, et on documente le choix dans le fichier
readme.txtde l’extension qui regroupe les blocs.
Notre verdict
Pour un bloc qui démarre en ce moment, les hooks React réduisent la quantité de code de câblage et méritent d’être adoptés par défaut. Mais rien n’oblige à réécrire les blocs existants qui fonctionnent déjà avec withSelect et withDispatch : les deux approches reposent sur le même magasin de données et produisent le même résultat, seule la syntaxe change.
