import { PanelBody, ToggleControl } from '@wordpress/components'; — cette ligne d’import remplace, à elle seule, plusieurs dizaines de lignes de balisage HTML et de feuille de style qu’aurait nécessitées un formulaire de réglages construit à la main pour une méthode d’expédition personnalisée.
Cette recette montre comment assembler un panneau de réglages cohérent avec l’interface de l’éditeur, pour une extension WC_Shipping_Method qui expose ses options dans un contexte bloc plutôt que dans un formulaire classique de page de réglages.
Le problème avec un formulaire HTML classique
Un formulaire HTML construit à la main pour exposer une option comme un délai de livraison estimé ou une case à cocher d’activation demande de reproduire manuellement l’espacement, la typographie et les états de focus déjà définis par l’interface de l’éditeur. Le résultat visuel diffère presque toujours légèrement du reste de l’interface, ce qui se remarque immédiatement dans un panneau qui côtoie des réglages natifs.
Le snippet commenté
import { PanelBody, ToggleControl, __experimentalNumberControl as NumberControl } from '@wordpress/components';
import { useState } from '@wordpress/element';
import { __ } from '@wordpress/i18n';
function PanneauMethodeExpedition() {
const [ activee, setActivee ] = useState( true );
const [ delaiJours, setDelaiJours ] = useState( 3 );
return (
<PanelBody title={ __( 'Livraison point relais express', 'mon-extension' ) } initialOpen={ true }>
<ToggleControl
label={ __( 'Activer cette méthode', 'mon-extension' ) }
checked={ activee }
onChange={ setActivee }
/>
<NumberControl
label={ __( 'Délai estimé (jours ouvrés)', 'mon-extension' ) }
value={ delaiJours }
onChange={ ( valeur ) => setDelaiJours( Number( valeur ) ) }
min={ 1 }
max={ 15 }
/>
</PanelBody>
);
}
Le composant PanelBody fournit à lui seul la structure repliable, l’espacement interne et la typographie du titre, sans aucune feuille de style additionnelle à écrire. ToggleControl et NumberControl héritent automatiquement de l’apparence des autres réglages natifs, y compris leur comportement au clavier pour la navigation entre champs.

Pourquoi ce choix dépasse la seule question esthétique
Au-delà de la cohérence visuelle, utiliser les composants officiels garantit un comportement accessible déjà validé par le projet : ordre de tabulation, description accessible du contrôle, prise en charge des lecteurs d’écran. Reproduire ce niveau d’accessibilité dans un formulaire HTML construit à la main demanderait un travail bien plus long que celui économisé en évitant l’import d’une bibliothèque déjà présente dans l’environnement de l’éditeur.
Ces composants s’adaptent aussi automatiquement à un thème d’interface sombre si l’utilisateur en a activé un, ce qui n’est pas garanti pour un balisage personnalisé sans travail supplémentaire.
Variantes possibles
- Remplacer
ToggleControlparCheckboxControlsi le réglage doit s’intégrer dans une liste de plusieurs cases à cocher plutôt qu’un interrupteur isolé. - Utiliser
SelectControlpour un choix parmi plusieurs zones de livraison prédéfinies plutôt qu’une simple case à cocher d’activation. - Regrouper plusieurs
PanelBodydans un composantPanelparent lorsque la méthode d’expédition expose plusieurs catégories de réglages distinctes.
Ce que cette recette ne couvre pas
Le calcul du tarif d’expédition lui-même, à partir du poids, du volume ou de la zone géographique du panier, reste entièrement séparé de ce panneau de réglages : il relève de la méthode calculate_shipping() de la classe WC_Shipping_Method, appelée indépendamment de l’interface qui expose ses options à l’administrateur.
En résumé
Construire ce panneau avec les composants officiels plutôt qu’un formulaire personnalisé demande d’apprendre une nouvelle bibliothèque, mais élimine en échange tout le travail de cohérence visuelle et d’accessibilité que la même interface, écrite à la main, aurait nécessité pour atteindre un résultat comparable.