Live data from Hacker News

Which is the best method for deep cloning in JavaScript?

medium.com

21–30 of 62 posts

Re: Which is the best method for deep cloning in JavaScript?

#21
post #15

Earlier quoted context omitted.

This fails, among other scenarios, if `someThing` includes a Date object. >>> const z = { d: new Date() } undefined >>> typeof z.d "object" >>> const a = JSON.parse(JSON.stringify(z)) undefined >>> typeof a.d "string" >>> After the roundtrip, the property `d` is now a string, not a Date object.

All the data comes from a JSON API and thus doesn't contain Date objects to begin with.

Makes sense for the most part with these constraints then. I missed the "primitive types" portion in the original comment.

The following isn't applicable for pure JSON responses, but is applicable for primitive types:

An additional condition for bigint is necessary, which is a primitive type. Otherwise JSON.stringify throws:

  >>> const x = { i: BigInt("0x1fffffffffffff") }
  undefined
  >>> typeof x.i
  "bigint"
  >>> const b = JSON.parse(JSON.stringify(x))
  Exception: TypeError: JSON.stringify cannot serialize BigInt.
  >>>
... and for the symbol primitive, which JSON.stringifys to undefined, and thus can't be JSON.parsed.

Re: Which is the best method for deep cloning in JavaScript?

#22

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.

Agreed. And not just in JavaScript.

Yes, sometimes you will want a deep copy. These are fewer and further between than online reading about it would have you think.

Re: Which is the best method for deep cloning in JavaScript?

#24

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.

In the case where you clone an object so the user can modify it while being able to revert back to the original object.

How is that a smell? or how would you refactor it?

Re: Which is the best method for deep cloning in JavaScript?

#25

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.

Re: Which is the best method for deep cloning in JavaScript?

#26

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.

Cloning is fairly common when you're writing functional style code with immutable objects. Not "code smell".

Re: Which is the best method for deep cloning in JavaScript?

#27
Right out of the gate they mention that the first approach listed doesn't clone Symbol...and then they treat this as a flaw.

I haven't used Symbol in JS much, but I was under the impression that it's _supposed_ to be a sorta "interned" value (in the sense that there exists exactly one instance in existence of each Symbol value)...which would mean that cloning them isn't a concept that makes sense.

My loose awareness of this particular JS type is leaving me quite un-confident in this understanding though, so I'd love for someone to correct me where I'm wrong so I can learn more!

Re: Which is the best method for deep cloning in JavaScript?

#28
post #25

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.

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 why your user would need to mutate it in the first place. If they want to change its internal structure then this is indicative of a code smell because your object is too big and the user cannot accomplish their goal by calling functions exposed by your API.

There was a phase in the JS ecosystem a few years ago where everything absolutely had to be immutable. This was, IMO, a horrible side effect of react developers optimizing their props for diffing during reconciliation. Libraries like immer and redux produced a lot of this zealotry.

I understand the purism appeal of "immutable everything," and I won't say it has no application, but it has been dogmatically over-applied to the point that you have people googling how to deep clone their config object with a nested function assignment because they're scared of passing a mutable object, and oh my god what if my user mutates it?

Re: Which is the best method for deep cloning in JavaScript?

#29
post #15

I only clone data using JSON.parse(JSON.stringify(someThing)), and thus avoid all the mess that comes with trying to clone anything else than primitives types.

This fails, among other scenarios, if `someThing` includes a Date object. >>> const z = { d: new Date() } undefined >>> typeof z.d "object" >>> const a = JSON.parse(JSON.stringify(z)) undefined >>> typeof a.d "string" >>> After the roundtrip, the property `d` is now a string, not a Date object.

[dead]
Post reply on HN