Chapitre 8.1 — Gutenberg pour un dev React

⏱️ TL;DR — L’éditeur de blocs est une application React. Un bloc est un composant : sa fonction edit rend l’aperçu dans l’éditeur, sa fonction save (ou un rendu PHP) produit le HTML final. WordPress fournit son propre écosystème de paquets @wordpress/* (element = React, blocks, components, data, block-editor, i18n) : c’est du React, avec des noms différents. Vous partez donc avec un avantage énorme — les concepts (JSX, props, état, hooks) sont identiques ; il faut surtout apprendre le vocabulaire et les API maison.

🎯 Objectifs

• Comprendre qu’un bloc est un composant React (edit/save).
• Traduire les paquets @wordpress/* en équivalents React connus.
• Repérer les différences (pas de import React, @wordpress/element, JSX via build).
• Situer les briques que les chapitres suivants détaillent.

1. Un bloc = un composant

Développer un bloc, c’est fournir :

• une définition (block.json : nom, attributs, supports…) ;
• une fonction edit : un composant React qui rend l’aperçu dans l’éditeur (interactif, avec réglages) ;
• une fonction save : ce qui est sérialisé dans le contenu (HTML statique), ou un rendu dynamique en PHP (ch. 8.5).

2. Les paquets @wordpress/* (votre dictionnaire)

WordPress a « re-packagé » React et un écosystème d’outils. Traduction :

💡 Pour un dev React — Mentalement : @wordpress/element est React, @wordpress/components est votre librairie de composants (comme MUI/Chakra), @wordpress/data est votre store (comme Redux/Zustand), @wordpress/api-fetch est votre client HTTP. Vous ne réapprenez pas React ; vous apprenez les noms et quelques conventions. 80 % de vos réflexes s’appliquent directement.

3. Les différences à connaître

• Pas d’import React from 'react' : on importe depuis @wordpress/element (ou on laisse le build injecter le JSX pragma). En pratique, avec @wordpress/scripts (ch. 8.2), le JSX « marche » sans config.
• JSX transpilé par le build : @wordpress/scripts fournit webpack + Babel préconfigurés. Vous écrivez du .js/.jsx moderne, il produit le bundle et un fichier .asset.php qui déclare les dépendances (wp-element, wp-blocks…) pour l’enqueue automatique.
• Deux rendus : edit (éditeur) et save/PHP (front). Un bloc statique doit que son save corresponde au HTML stocké (sinon « invalidation », ch. 3.1) → beaucoup de blocs « à données » sont dynamiques (rendu PHP) pour éviter ça.
• Le contexte éditeur : dans edit, vous avez accès aux données de WordPress (le post courant, ses meta, les entités) via @wordpress/data (ch. 8.7) — pas via des props passées manuellement.

4. Un aperçu de code (pour situer)

Un bloc statique minimal (détaillé au ch. 8.3) :

import { registerBlockType } from '@wordpress/blocks';
import { useBlockProps, RichText } from '@wordpress/block-editor';
import { __ } from '@wordpress/i18n';
import metadata from './block.json';
 
registerBlockType( metadata.name, {
    edit( { attributes, setAttributes } ) {
        const blockProps = useBlockProps();
        return (
            <div { ...blockProps }>
                <RichText
                    tagName="h3"
                    value={ attributes.titre }
                    onChange={ ( titre ) => setAttributes( { titre } ) }
                    placeholder={ __( 'Titre…', 'wpr-books' ) }
                />
            </div>
        );
    },
    save( { attributes } ) {
        const blockProps = useBlockProps.save();
        return <RichText.Content tagName="h3" value={ attributes.titre } { ...blockProps } />;
    },
} );

Vous reconnaissez tout : composant, props (attributes), handler (onChange → setAttributes, l’équivalent d’un setState), JSX. Le vocabulaire (useBlockProps, RichText, setAttributes) est la seule nouveauté.

5. Le plan de la partie

On avance ainsi : scaffolding (ch. 8.2) pour ne pas configurer le build à la main → edit/save/attributs (8.3) → contrôles (8.4) → dynamique (8.5) → composition (8.6) → data stores (8.7) → variations/styles (8.8) → tutoriel (8.9). À la fin, vous saurez livrer un bloc réel, branché sur wpr-books.

✏️ Exercices

1. Reliez chaque paquet à son équivalent : @wordpress/element, @wordpress/data, @wordpress/components, @wordpress/api-fetch.
2. Quelles sont les deux fonctions clés d’un bloc, et que produit chacune ?
3. Pourquoi de nombreux blocs « à données » sont-ils rendus en PHP (dynamiques) plutôt qu’avec save ?

🧠 Quiz de révision

Chapitre suivant : Scaffolding : @wordpress/scripts & block.json.