4 ms·

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 sm

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.

taeric 4y ago
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.
bottlepalm 4y ago
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?
pubby 4y ago
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.
- TechBro8615 4y ago
  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?
  - gloryjulio 4y ago
    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
- guluarte 4y ago
  you'll be surprised a lot of webdevs don't know the difference between a value and a ref type
DrJokepu 4y ago
Cloning is fairly common when you're writing functional style code with immutable objects. Not "code smell".
- fnordsensei 4y ago
  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.
  - DrJokepu 4y ago
    Copy-on-write is a common operation on immutable data and deep cloning is how you do that in JavaScript in a safe manner.
    - deleted 4y ago
      [deleted]
    - fnordsensei 4y ago
      Oh yeah, that’s true. I was thinking of RRB trees, hash array mapped tries and things like this.
- gloryjulio 4y ago
  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).
deleted 4y ago
[deleted]
guluarte 4y ago
cloning is extremelly common in js
claytongulick 4y ago
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/ https://jsonpatch.com/ [2] https://www.npmjs.com/package/fast-json-patch https://www.npmjs.com/package/fast-json-patch
ravenstine 4y ago
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.
voyager1 4y ago
Have you used React? You must copy every complex object or list everytime before you update the state.
- nishs 4y ago
  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-updates-are-merged https://reactjs.org/docs/state-and-lifecycle.html#state-upda... In Redux reducers, however, you need a full copy.
8bitsrule 4y ago
I've avoided writing objects altogther. Never ran across a problem I needed them for.

taeric 4y ago

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.

bottlepalm 4y ago

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?

pubby 4y ago

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.

TechBro8615 4y ago
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?
- gloryjulio 4y ago
  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
guluarte 4y ago
you'll be surprised a lot of webdevs don't know the difference between a value and a ref type

DrJokepu 4y ago

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

fnordsensei 4y ago
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.
- DrJokepu 4y ago
  Copy-on-write is a common operation on immutable data and deep cloning is how you do that in JavaScript in a safe manner.
  - deleted 4y ago
    [deleted]
  - fnordsensei 4y ago
    Oh yeah, that’s true. I was thinking of RRB trees, hash array mapped tries and things like this.
gloryjulio 4y ago
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).

deleted 4y ago

[deleted]

guluarte 4y ago

cloning is extremelly common in js

claytongulick 4y ago

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/ https://jsonpatch.com/ [2] https://www.npmjs.com/package/fast-json-patch https://www.npmjs.com/package/fast-json-patch

ravenstine 4y ago

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.

voyager1 4y ago

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

nishs 4y ago
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-updates-are-merged https://reactjs.org/docs/state-and-lifecycle.html#state-upda... In Redux reducers, however, you need a full copy.

8bitsrule 4y ago

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