Annonce de l'abandon et de la suppression planifiée des événements de mutation, et explique comment migrer votre code avant sa suppression en juillet 2024.
Chromium a officiellement abandonné les événements de mutation et prévoit de supprimer leur compatibilité à partir de la version 127, qui sera disponible en version stable le 23 juillet 2024. Cet article explique pourquoi nous supprimons les événements de mutation et indique comment effectuer la migration avant qu'ils ne soient supprimés du navigateur.
Que sont les événements de mutation ?
Les événements de mutation sont le nom de la collection d'événements suivante:
DOMNodeInsertedDOMNodeRemovedDOMSubtreeModifiedDOMCharacterDataModifiedDOMNodeInsertedIntoDocumentDOMNodeRemovedFromDocument- (Non compatible avec les navigateurs récents)
DOMAttrModified - (Non compatible avec les navigateurs récents)
DOMAttributeNameChanged - (Non compatible avec les navigateurs récents)
DOMElementNameChanged
Ces événements font partie des spécifications du DOM de niveau 2, et sont abandonnés depuis 2011. Elles ont été remplacées par l'interface MutationObserver, qui est compatible avec tous les navigateurs récents depuis 2013.
Historique des événements de mutation
Il y a longtemps, les événements de mutation semblaient être une bonne idée, mais ils comportaient plusieurs erreurs fatales:
- Ils sont verbeux et se déclenchent trop souvent. Un événement est déclenché pour chaque nœud supprimé.
- Elles sont lentes, en raison de la propagation des événements et empêchant de nombreuses optimisations de l'exécution d'UA.
- Ils provoquent souvent des plantages. Ils sont à l'origine de nombreux plantages et bugs de sécurité dans les navigateurs, car les écouteurs d'événements peuvent modifier l'intégralité du DOM sous une opération DOM en cours d'exécution.
En raison de ces failles, ces événements ont été abandonnés dans la spécification en 2011 et une API de remplacement (MutationObserver) a été créée en 2012. La nouvelle API est implémentée et fonctionnelle depuis plus de 10 ans.
Pourquoi des événements de mutation sont-ils supprimés ?
La prise en charge des événements de mutation varie selon les navigateurs. Certains événements, comme DOMNodeInsertedIntoDocument et DOMNodeRemovedFromDocument, ne sont pas compatibles avec tous les navigateurs. Pour les autres événements, le comportement spécifique varie en raison de l'absence de spécification convenue. Toutefois, il se peut que vous vous posiez la question suivante: pourquoi ne pas simplement les laisser là, puisqu'ils sont "terminés" et qu'ils ne font que ralentir les pages qui les utilisent ? La réponse comporte deux parties.
Premièrement, ces événements freinent la plate-forme Web. À mesure que le Web évolue et que de nouvelles API sont ajoutées, l'existence de ces anciennes API doit être prise en compte. Parfois, la seule nécessité de gérer ces événements peut empêcher la proposition de nouvelles API. Par exemple, une demande de longue date empêche l'actualisation des éléments <iframe> lorsqu'ils sont déplacés dans le DOM. Cependant, en partie en raison de l'existence d'événements de mutation, cet effort a été jugé trop difficile à réaliser, et la demande a été clôturée.
Ces événements continuent d'entraver l'accélération des navigateurs. Même si les navigateurs effectuent des optimisations pour éviter les problèmes de performances sur les pages qui n'utilisent pas d'événements de mutation, tout n'est pas parfait. Les écouteurs d'événements de mutation doivent tout de même être vérifiés à de nombreux endroits. Le code doit tout de même être écrit de manière très défensive, car ces événements peuvent modifier le DOM de manière surprenante.
Comme plus de 10 ans se sont écoulés depuis l'abandon officiel des événements, et que l'API de remplacement est également disponible depuis plus de 10 ans, le moment est venu de supprimer définitivement les événements de mutation des navigateurs.
Comment procéder ?
Utilisez plutôt MutationObserver
La documentation de MutationObserver se trouve sur MDN et est assez complète. Le remplacement de votre codebase dépend de la manière dont ces événements sont utilisés, mais à titre d'exemple:
// Old mutation event usage:
target.addEventListener(‘DOMNodeInserted',event => doSomething(event.target));
// Replacement mutation observer code:
const observer = new MutationObserver(mutationList =>
mutationList.filter(m => m.type === 'childList').forEach(m => {
m.addedNodes.forEach(doSomething);
}));
observer.observe(target,{childList: true, subtree: true});
Bien que le code MutationObserver semble plus grand que le code d'origine de l'écouteur d'événements DOMNodeInserted, notez qu'il peut gérer toutes les mutations qui se produisent sur une arborescence entière en un seul appel, au lieu de nécessiter plusieurs appels au gestionnaire d'événements.
Polyfill
Un polyfill tente de permettre au code existant de continuer à fonctionner tout en étant alimenté par MutationObserver. Le polyfill se trouve sur GitHub ou en tant que package npm.
- https://github.com/mfreed7/mutation-events-polyfill#readme
- https://www.npmjs.com/package/mutation-events
Calendrier et informations sur l'abandon de l'essai
Les événements de mutation seront supprimés de Chrome 127 pour tous les utilisateurs*. Ils passeront à la version stable le 23 juillet 2024. Nous commencerons à supprimer les événements des versions Canary, en développement et bêta avant cette date, pour vous en informer.
- Si vous avez besoin de plus de temps (au-delà de juillet 2024) pour migrer votre code, une évaluation avant arrêt réactive les événements temporairement sur les sites spécifiés. Il existe également une règle d'entreprise appelée
MutationEventsEnabled, qui fonctionne de manière similaire pour les utilisateurs professionnels. Pour chacune de ces options, environ neuf mois supplémentaires sont nécessaires pour procéder à la migration, si nécessaire.