Éviter JSON pour la copie en profondeur en JS

Ha mais JSON.parse(JSON.stringify(…)) est un vrai truc canonique en Javascript ?

Quand j’ai vu ça dans la base de code que j’ai récupéré, j’ai cru que c’était une invention de plus des types qui avaient pondu l’horreur lovecraftienne que constitue le reste du projet.

C’est une des top réponses dans pas mal de fils de discussion sur stackoverflow malheureusement… Pire, je suis tombé sur un lien aujourd’hui (que je ne retrouve pas) d’une version d’eloquent javascript d’un tuto où était présenté clonedeep et JSON.parse(JSON.stringify(…)) côte à côte…

Pendant un moment, j’ai pensé que mon problème de performance venait des composants en plus.

C’est bien une solution courante oui @Spacefox, qui a l’avantage d’être simple à mettre en place. Forcément sur des petits besoins une petite solution peut faire le job.

Mais il faut forcément s’attendre à avoir des performances limitées quand on transforme un objet dans un format structuré… qu’on parse ensuite intégralement pour re-construire un nouvel objet de zéro.

Comme souvent, le plus important est de savoir ce qu’on veut prioriser : les performances d’exécution, la taille de la base de code, la dépendance à des libs externes…

Merci !

Si je comprends bien, le standard structuredClone est récent (2022), d’ou la présence massive de JSON.parse(JSON.stringify(…)) ou de lodash malgré ses problèmes de performance passés ?

En effet, les premières implémentations sont arrivées fin 2022 (Firefox) voire début 2023 (Chrome & co) sur le marché, donc pas mal de code historique aura encore des vestiges du passé de la sorte

Encore plus pour les projets qui veulent conserver une rétro-compatibilité, par exemple avec Netscape IE11…

Et on peut s’apercevoir que la lenteur vient d’une lib qu’on utilise, et qui utilise cette technique en interne.

Au pif… vuex-pathify. Lib beaucoup utilisé avec Vue 2, désuet aujourd’hui.