# withSelect et withDispatch contre les hooks React : lequel choisir en 2020

> Deux façons de connecter un bloc au magasin de données WordPress cohabitent en 2020. Comparatif concret pour démarrer un nouveau bloc sans se tromper de convention.

- Auteur : WordPress Développement
- Publié le : 2020-05-05
- Mis à jour le : 2020-05-05
- Catégorie : Blocs Gutenberg
- URL : https://www.wpmoderne.fr/blocs/withselect-withdispatch-contre-hooks-react-2020/

## L’essentiel

- withSelect et withDispatch restent pleinement supportés
- useSelect et useDispatch réduisent le nombre de composants imbriqués
- Le choix dépend surtout des conventions déjà en place sur le projet

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

> L'essentiel à retenir : withSelect et withDispatch restent pleinement supportés ; useSelect et useDispatch réduisent le nombre de composants imbriqués ; Le choix dépend surtout des conventions déjà en place sur le projet

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 avec `withSelect`/`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.txt` de 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.