# « Cannot read properties of undefined » après une màj de @wordpress/components

> Diagnostic d'un plantage d'éditeur causé par un composant renommé entre deux versions de @wordpress/components, avec le correctif d'import à appliquer.

- Auteur : WordPress Développement
- Publié le : 2021-06-21
- Mis à jour le : 2021-06-21
- Catégorie : Blocs Gutenberg
- URL : https://www.wpmoderne.fr/blocs/erreur-cannot-read-properties-undefined-wordpress-components/

## L’essentiel

- L'erreur pointe vers React, pas vers la vraie cause
- Un composant a changé de chemin d'import entre deux versions
- Le correctif tient en une ligne une fois la cause isolée

« Cannot read properties of undefined (reading 'Item') » — l'écran blanc de l'éditeur qui suit ce message ne donne aucune indication sur le bloc ou le composant réellement en cause. La stack trace pointe vers un fichier minifié de React, ce qui n'aide en rien à remonter jusqu'à la ligne de code fautive dans l'extension.

Ce plantage est apparu après la mise à jour du cœur WordPress vers une version embarquant une nouvelle édition de `@wordpress/components`, sans que rien n'ait changé dans le code du bloc lui-même. La cause : un composant utilisé par le bloc avait changé de structure interne entre les deux versions.

## Comprendre pourquoi l'erreur est aussi vague

WordPress ne fige pas `@wordpress/components` comme une dépendance npm classique installée localement : le paquet `wp-components` côté navigateur correspond à la version embarquée dans le cœur WordPress installé sur le site, potentiellement différente de celle utilisée en développement local si le fichier `package.json` de l'extension n'a pas été mis à jour en conséquence.

Un composant peut alors exposer une structure différente (sous-composant renommé, prop renommée, export déplacé) sans qu'aucun avertissement explicite ne l'indique avant le plantage en runtime.

## Isoler le composant fautif

La première étape a consisté à commenter, un par un, les imports du fichier `edit.js` jusqu'à faire disparaître l'erreur — une méthode rudimentaire mais efficace sur un fichier de taille raisonnable :

```
import { Dropdown, MenuGroup, MenuItem } from '@wordpress/components';
// ...
<Dropdown
    renderContent={ () => (
        <MenuGroup>
            <MenuGroup.Item>Option 1</MenuGroup.Item>
        </MenuGroup>
    ) }
/>
```

> L'essentiel à retenir : L'erreur pointe vers React, pas vers la vraie cause ; Un composant a changé de chemin d'import entre deux versions ; Le correctif tient en une ligne une fois la cause isolée

## La vraie cause : un accès à une propriété qui n'existe plus

Le code utilisait `MenuGroup.Item` comme sous-composant, un pattern qui fonctionnait sur l'ancienne version de la librairie mais qui n'était en réalité jamais officiellement documenté de cette façon. La version mise à jour de `@wordpress/components` exposait `MenuItem` comme composant autonome, à importer séparément — ce qui était d'ailleurs déjà fait plus haut dans le fichier, sans être utilisé correctement :

```
// Correctif
<Dropdown
    renderContent={ () => (
        <MenuGroup>
            <MenuItem>Option 1</MenuItem>
        </MenuGroup>
    ) }
/>
```

Une ligne changée, et l'éditeur redevient fonctionnel. Le vrai travail a consisté à isoler cette ligne parmi plusieurs centaines de lignes de composants imbriqués.

## Réduire le risque pour la prochaine mise à jour

- Consulter le `CHANGELOG.md` du paquet `@wordpress/components` avant toute montée de version majeure de WordPress, disponible sur le dépôt GitHub officiel du projet Gutenberg.
- Éviter les patterns non documentés, même s'ils fonctionnent visuellement : un sous-composant accédé via la notation pointée sans être exporté explicitement de cette façon reste un pari sur la stabilité interne de la librairie.
- Tester chaque mise à jour de WordPress sur un environnement de recette avant la production, avec un passage rapide sur chaque écran d'édition contenant des blocs personnalisés.
- Ajouter un test end-to-end minimal qui ouvre l'éditeur et vérifie l'absence d'erreur JavaScript en console, avec `@wordpress/e2e-test-utils`.

## Ce que cet article ne couvre pas

La migration complète de toutes les dépendances `@wordpress/*` d'une extension vers leurs dernières versions demande une revue bien plus large que ce seul correctif ponctuel. Le passage à `apiVersion 3` et à l'éditeur en iframe, qui change également la façon dont certains styles et composants se comportent, mérite un traitement séparé et plus complet.

## En résumé

Une erreur JavaScript vague qui pointe vers React n'implique jamais un bug de React lui-même : elle signale presque toujours un décalage entre le code de l'extension et la version réelle des dépendances WordPress chargées en production. Isoler le composant en cause, ligne par ligne si nécessaire, reste la méthode la plus fiable quand la stack trace n'aide pas.