TypeError: Cannot destructure property 'valeur' of 'attributes' as it is undefined. Ce message, jeté en pleine face dans la console du navigateur, accompagne souvent un écran d’édition figé et blanc, sans le moindre indice visuel sur le bloc fautif. Il apparaît presque toujours après une modification anodine de la déclaration d’un bloc, sur du contenu publié avant ce changement.
Ce billet retrace le diagnostic complet de cette erreur sur un bloc « fiche produit » personnalisé, et propose un correctif durable. La validation de contenu après une mise à jour de bloc, sujet voisin, est traitée ailleurs et ne sera pas reprise ici.
Le symptôme observé dans l’éditeur
Sur un projet où un bloc « fiche produit » affichait un prix et une référence, un attribut reference a été ajouté après coup, pour permettre un tri par référence côté front. Rien d’exceptionnel : une simple modification JavaScript dans la définition des attributs du bloc, suivie d’une déclaration de valeur par défaut oubliée.
Résultat : tous les articles publiés avant cet ajout affichaient un écran d’édition entièrement vide à l’ouverture, avec l’erreur Cannot destructure property 'reference' of 'attributes' as it is undefined dans la console. Le contenu existait bien en base, mais l’éditeur refusait de le charger.
Comprendre pourquoi l’attribut manquait
La fonction d’édition du bloc déstructurait directement les attributs à la racine de la fonction, sans protection :
function edit( { attributes, setAttributes } ) {
const { prix, reference } = attributes;
// reference est undefined sur le contenu ancien
}Sur un contenu créé avant l’ajout de l’attribut reference, cet attribut n’existe simplement pas dans les données sérialisées de l’article. Sans valeur par défaut déclarée, JavaScript ne peut pas déstructurer une propriété absente d’un objet dont une sous-clé est elle-même undefined, et l’éditeur s’arrête net avec une page blanche.
Le correctif : une valeur par défaut à la déclaration
La correction tient en une ligne, dans la déclaration JavaScript des attributs du bloc, avec l’argument default :
attributes: {
prix: {
type: 'string',
default: '',
},
reference: {
type: 'string',
default: '',
},
},Dès qu’une valeur par défaut existe, WordPress la complète automatiquement sur le contenu ancien qui n’a jamais eu cet attribut, sans qu’aucune migration manuelle des articles publiés ne soit nécessaire. L’éditeur retrouve un objet attributes complet, et la déstructuration ne plante plus.
Sécuriser aussi le rendu, par précaution
Même avec une valeur par défaut bien déclarée, une protection supplémentaire dans le rendu évite toute mauvaise surprise si un contenu très ancien contourne malgré tout la déclaration :
const { prix = '', reference = '' } = attributes || {};Cette double sécurité, valeur par défaut à la déclaration et valeur par défaut à la déstructuration, coûte peu et protège contre les cas limites, notamment un contenu importé depuis une autre installation WordPress.
Prévenir plutôt que corriger dans l’urgence
- Toujours déclarer une valeur par défaut pour chaque nouvel attribut, dès sa création
- Tester l’ouverture d’un article ancien après chaque modification d’attributs, pas seulement un article neuf
- Ne jamais déstructurer
attributessans filet en tout début de fonction d’édition
Sur un projet avec plusieurs blocs personnalisés en évolution constante, cette vérification systématique évite l’essentiel des tickets « l’éditeur est cassé » qui remontent après une mise à jour du thème ou de l’extension.
Ajouter un attribut à un bloc déjà utilisé en production, sans valeur par défaut, revient à retirer une marche d’escalier sans prévenir personne : la chute n’arrive pas tout de suite, mais elle arrive.
Pour aller plus loin
Cette erreur, très fréquente dans les premières années du développement de blocs, se corrige presque toujours de la même façon : une valeur par défaut oubliée. Sur un bloc amené à évoluer, mieux vaut prendre l’habitude de toujours accompagner l’ajout d’un attribut d’une valeur par défaut explicite, avant même d’écrire la logique qui l’utilise.
