cloneDeep maintains reference after cloning?

[hulbert]

Not sure if this is intended, it doesn't match what I use _.cloneDeep for but perhaps it's desired for other cases. It came up unexpectedly in our codebase so I'd be curious—if it's intended behavior—if it could be documented clearly.

It seems that _.cloneDeep maintains, in the cloned object, two keys referencing the same object in the original object.

Example case:

'use strict'

let _ = require('lodash')

let x = { lodash: 'isgreat' }

let y = { 
    one: x,
    two: x,
    three: { 
        javascript: 'isfun' 
    }
}

console.log('One and two are equal in original object?', y.one === y.two)

let yy = _.cloneDeep(y)

console.log('One and two are equal in deep cloned object?', yy.one === yy.two)
console.log('One is different object before and after clone?', y.one === yy.one)

This prints:

One and two are equal in original object? true
One and two are equal in deep cloned object? true
One is different object before and after clone? false

I would have expected it to print:

One and two are equal in original object? true
One and two are equal in deep cloned object? false
One is different object before and after clone? false

[jdalton]

Hi @hulbert!

Our _.cloneDeep method supports circular references. So

y.one === y.two // true
yy.one === y.one // false
yy.one === yy.two // true

[hulbert]

@jdalton would you accept a PR to better document this behavior?

Additionally, is there a way to deep clone without this behavior in lodash. The use case is a large object/document that may need to be mutated but has some duplicate values via reference to avoid repetition and clarify that they're the same. In our case, a large deeply nested settings object for configuring a job.

[jdalton]

The clone behavior is glossed over as "This method is loosely based on the structured clone algorithm". See http://w3c.github.io/html/infrastructure.html#section-structuredclonewithtransfer

The purpose of the memory map, both here and in the StructuredClone abstract operation, is to avoid cloning objects twice. This ends up preserving cycles and the identity of duplicate objects in graphs.

You might be able to customize the cloning behavior with _.cloneDeepWith.

[iabw]

I would also vote for it to be better documented that this is the case.

Especially since many sources

inadequately or incompletely explain lodash's clone:

• https://stackoverflow.com/questions/21851974/lodash-clone-and-clonedeep-behaviors
• https://stackoverflow.com/questions/25654389/why-is-jquery-extend-faster-than-lodash-clone

incorrectly equate it with jQuery's deep extend:

• https://jsperf.com/underscore-clone-vs-jquery-extend-2/37
• https://jsperf.com/deep-clone-lodash-vs-jquery

or don't mention lodash at all, when it would be worth a footnote:

• https://stackoverflow.com/questions/122102/what-is-the-most-efficient-way-to-deep-clone-an-object-in-javascript?rq=1
• https://stackoverflow.com/questions/18359093/how-to-copy-javascript-object-to-new-variable-not-by-reference?noredirect=1&lq=1

I think the only mention of this behavior that I've managed to find is this issue. Even the link to MDN in _.clone's description only says recursing through the input object while maintaining a map of previously visited references, which might be argued is not explicit enough about what is actually included in the final result.

Just adding a minimal repro to the examples for _.clone and _.cloneDeep (like the one @hulbert included above) would probably save some headaches.

[vhf]

Agreed, an answer to this:

@jdalton would you accept a PR to better document this behavior?

would be welcome. 👍

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.