Hacker News Reader

Comment by TechBro8615 | Hacker News Reader

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.

View on HN

It may be rare that you need to deep clone, but doing so can be a good idea nonetheless. Sometimes I want a function to not be able to mutate the original object that informs it, in which case it will receive a deep clone or return a brand new object. I find this can make complex code easier to comprehend because I can have greater confidence that return values are new and functions aren't causing side effects. Of course you can never guarantee this in JavaScript, but it's worth making a best attempt IMO.

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?

But in React you never need to deep clone the object? The same principles apply to all the same breed of framework btw, vue/angular etc only updates what you r updating. You are supposed to make a new reference of the object but the fields of would be of the old references except the field you want to update. If you are deep cloning the whole thingy then the performance is actually worse because you r doing unnecessary updates. You could use spread operator to easily make a new object reference. Nowadays you have immerjs to do the grunt work for you

you'll be surprised a lot of webdevs don't know the difference between a value and a ref type

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

But if you are doing more functional style, you would be copying the reference, NOT the object. Functional style makes you need LESS of deep copy. See immerjs

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).

But when you’re using immutable data, deep cloning is not something you need for to worry about. So it kind of is an anti-pattern in this case.

Copy-on-write is a common operation on immutable data and deep cloning is how you do that in JavaScript in a safe manner.

Oh yeah, that’s true. I was thinking of RRB trees, hash array mapped tries and things like this.

Cloning is super useful and not a code smell at all in several scenarios.

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.

[1] https://jsonpatch.com/

[2] https://www.npmjs.com/package/fast-json-patch

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?

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.

Have you used React? You must copy every complex object or list everytime before you update the state.

s/React/Redux? (for example)

With setState in React, you don't necessarily have to copy to update the state. setState merges the partial object you provide with the current state.

https://reactjs.org/docs/state-and-lifecycle.html#state-upda...

In Redux reducers, however, you need a full copy.

I've avoided writing objects altogther. Never ran across a problem I needed them for.

cloning is extremelly common in js

Reply on news.ycombinator.com