Combien d’attributs de bloc faut-il pour représenter « à quelle étape du tunnel se trouve l’acheteur » ? Sur un premier essai de personnalisation du bloc Paiement de WooCommerce Blocks, la réponse était : un attribut par étape, plus un attribut pour savoir si l’étape précédente était validée, plus un attribut pour l’affichage conditionnel d’un résumé. Cinq attributs pour représenter trois états possibles.
Cette accumulation d’attributs devenait difficile à suivre dès que deux composants avaient besoin de lire le même état d’avancement sans passer par une chaîne de props profonde. Le passage à un store @wordpress/data dédié a nettement simplifié cette architecture.
Le problème des attributs de bloc dispersés
Un attribut de bloc convient très bien pour une valeur de configuration statique, définie une fois par l’utilisateur dans l’éditeur. Il convient beaucoup moins bien pour un état qui change dynamiquement pendant le parcours d’achat côté front, comme l’étape courante d’un tunnel en plusieurs pages virtuelles affichées sans rechargement complet.
Sur ce projet, le tunnel personnalisé comportait trois étapes : livraison, paiement, confirmation. Chaque étape devait pouvoir lire et modifier l’état global sans connaître les détails d’implémentation des autres composants, ce qu’un empilement de props rendait fragile au moindre réagencement de la structure des composants React.
Créer un store dédié avec @wordpress/data
La solution retenue a consisté à déclarer un store spécifique à ce tunnel, avec registerStore(), séparé du store natif de WooCommerce Blocks. Ce store expose un état minimal : l’étape courante, la validation de chaque étape précédente, et un indicateur de chargement pendant la validation du paiement.
import { registerStore } from '@wordpress/data';
const DEFAULT_STATE = {
etapeCourante: 'livraison',
etapesValidees: [],
enChargement: false,
};
const actions = {
passerAEtape( etape ) {
return { type: 'PASSER_A_ETAPE', etape };
},
validerEtape( etape ) {
return { type: 'VALIDER_ETAPE', etape };
},
};
function reducer( state = DEFAULT_STATE, action ) {
switch ( action.type ) {
case 'PASSER_A_ETAPE':
return { ...state, etapeCourante: action.etape };
case 'VALIDER_ETAPE':
return {
...state,
etapesValidees: [ ...state.etapesValidees, action.etape ],
};
default:
return state;
}
}
const selectors = {
getEtapeCourante( state ) {
return state.etapeCourante;
},
estEtapeValidee( state, etape ) {
return state.etapesValidees.includes( etape );
},
};
registerStore( 'monprojet/tunnel-commande', {
reducer,
actions,
selectors,
} );
Chaque composant du tunnel peut ensuite lire l’état courant via useSelect et déclencher une transition via useDispatch, sans jamais recevoir l’état complet en prop depuis un composant parent.
Ce que ce découpage apporte concrètement
Trois bénéfices se sont dégagés une fois le store en place :
- Un composant de test peut simuler n’importe quelle étape en appelant directement l’action correspondante, sans reproduire tout le parcours d’achat.
- L’ajout d’une quatrième étape, envisagée en cours de projet, n’a nécessité aucune modification des composants existants, seulement une extension du reducer.
- Le résumé de commande, affiché dans un composant totalement séparé du formulaire de livraison, lit l’état de validation sans dépendance directe à ce formulaire.
Une limite à connaître
Ce store reste un état côté client, réinitialisé à chaque rechargement complet de la page. Il ne remplace donc pas la persistance réelle des données de commande côté serveur : la validation finale d’une étape doit toujours être confirmée par un appel à l’API Store de WooCommerce avant de considérer l’étape comme réellement acquise, sous peine d’afficher un état incohérent si la requête serveur échoue silencieusement.
Synchroniser le store avec la réponse serveur
const { validerEtape } = useDispatch( 'monprojet/tunnel-commande' );
async function validerLivraison( donneesLivraison ) {
const reponse = await enregistrerLivraison( donneesLivraison );
if ( reponse.succes ) {
validerEtape( 'livraison' );
}
}
Un store côté client doit toujours rester un reflet de la réalité serveur, jamais une source de vérité autonome sur un tunnel d’achat : c’est la règle que je rappelle à chaque développeur qui découvre @wordpress/data sur ce genre de projet.
Notre verdict
Pour un tunnel de commande de trois étapes ou plus, un store @wordpress/data dédié apporte une clarté que les attributs de bloc ne peuvent pas offrir passé un certain niveau de complexité. Pour une personnalisation plus légère, comme l’ajout d’un simple champ optionnel, cette architecture serait surdimensionnée : les attributs de bloc classiques restent alors largement suffisants.
