I've been programming JavaScript for ~10 years now (wtf) and I've yet to encounter a case where I needed to "deep clone" an object. It has always been a code smell indicative of a need for some other structural refactoring.
I'm coming from a c++ and functional perspective but this seems very counter intuitive to me. Can you explain why they're bad? My assumption was it's easier to reason about objects the less they share.
Which is the best method for deep cloning in JavaScript?
31–40 of 62 posts
Re: Which is the best method for deep cloning in JavaScript?
#32I've been programming JavaScript for ~10 years now (wtf) and I've yet to encounter a case where I needed to "deep clone" an object. It has always been a code smell indicative of a need for some other structural refactoring.
Re: Which is the best method for deep cloning in JavaScript?
#33Re: Which is the best method for deep cloning in JavaScript?
#34structuredClone() https://developer.mozilla.org/en-US/docs/Web/API/structuredC...
Re: Which is the best method for deep cloning in JavaScript?
#35structuredClone() https://developer.mozilla.org/en-US/docs/Web/API/structuredC...
For real.
* Prototypes: structuredClone discards the object’s prototype chain.
* Functions: structuredClone quietly discards functions.
* Non-cloneables: structuredClone throws for some common values, e.g. Node, Error.
Re: Which is the best method for deep cloning in JavaScript?
#36It may look like for simple use cases the JSON one works. But one thing not included in this page is that there are things it just doesn't serialize, even when it's actual data: const native = { number: Number.POSITIVE_INFINITY }; const cloned = JSON.parse(JSON.stringify(native)); // unlike NaN, we can compare Number.POSITIVE_INFINITY to itself console.log(native.number === native.number); // but it doesn't serialize…
This is because inf and nan were left out of the json spec, right? Great format
Re: Which is the best method for deep cloning in JavaScript?
#37I've been programming JavaScript for ~10 years now (wtf) and I've yet to encounter a case where I needed to "deep clone" an object. It has always been a code smell indicative of a need for some other structural refactoring.
Cloning is fairly common when you're writing functional style code with immutable objects. Not "code smell".
Also your object won't be that complicated in the first place, they would be treated as plain data object like struct or record. And you would not use those advanced features in objects(Not needed).
Re: Which is the best method for deep cloning in JavaScript?
#38I've been programming JavaScript for ~10 years now (wtf) and I've yet to encounter a case where I needed to "deep clone" an object. It has always been a code smell indicative of a need for some other structural refactoring.
My most common use is for delta detection and json-patch based APIs.
I keep the original entity and allow the user to modify a clone.
When it's time to sync, I compare it to the original to generate a patch set to send to the server with json-patch [1] semantics.
I highly recommend the excellent fast-json-patch library [2] that makes this process a breeze.
Actually, I use its deepClone method outside of json-patch scenarios, it's so well implemented.
Re: Which is the best method for deep cloning in JavaScript?
#39Earlier quoted context omitted.
I'm coming from a c++ and functional perspective but this seems very counter intuitive to me. Can you explain why they're bad? My assumption was it's easier to reason about objects the less they share.
If you're reaching for deep cloning, your objects are too big. You're passing too much data between functions. The one exception is "actual" data which is (de-)serializable to/from JSON without any special cases (getters, functions, etc). But if it's an object that was programmatically constructed, then it can probably be made smaller. If your object is "deep" because of real nested dependencies, then you should ask…