You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An original issue #5269 was originally filed about this, but there was no feedback from the issue creator, and it was closed.
My team is experiencing the same situation. However, ours would not be correctly fixed by omitting the original value before merging as was done by a second commenter on that issue.
-- Original issue text starts (as it is still applicable) --
If property of the source objects is created from a class, it will be mutated.
import{merge}from"lodash"classsomeClass{aa=0}constsrc1={pg: {a: newsomeClass()}}constsrc2={pg: {a: {aa: 2}}}console.log(JSON.stringify(src1))// {"pg":{"a":{"aa":0}}}console.log(JSON.stringify(src2))// {"pg":{"a":{"aa":2}}}constdest=merge({},src1,src2)console.log(JSON.stringify(src1))// {"pg":{"a":{"aa":2}}} // However, aa should still be 0console.log(JSON.stringify(src2))// {"pg":{"a":{"aa":2}}}
-- Original issue text ends --
Our situation is the same; we are working with an options object for some widget which contains a renderer where the default renderer is an instance of a basic "Renderer" object.
When instantiating a new widget, the author is allowed to provide an object that conforms to the same interface as the "Renderer", but does not have to extend it.
When the new widget is created, the custom render function on the Renderer is attached to the default instance, causing future widgets to use that render function instead:
Definitely unexpected. This should not have the overridden render function as an instance property. Also, this is === to widget.#options.renderer which is definitely wrong.
Now when instantiating a separate widget with no overrides:
I believe that this behavior is a regression from Lodash 3. You can see the difference in behavior between the two here: https://jsfiddle.net/2y7hkzox/
It seems possible that there is a change between the behavior of baseMergeDeep. (Lodash 3's
An original issue #5269 was originally filed about this, but there was no feedback from the issue creator, and it was closed.
My team is experiencing the same situation. However, ours would not be correctly fixed by omitting the original value before merging as was done by a second commenter on that issue.
-- Original issue text starts (as it is still applicable) --
If property of the source objects is created from a class, it will be mutated.
-- Original issue text ends --
Our situation is the same; we are working with an options object for some widget which contains a renderer where the default renderer is an instance of a basic "Renderer" object.
When instantiating a new widget, the author is allowed to provide an object that conforms to the same interface as the "Renderer", but does not have to extend it.
When the new widget is created, the custom
render
function on the Renderer is attached to the default instance, causing future widgets to use thatrender
function instead:Results in:
widget.#options.renderer
:Which is OK, but a little unexpected. I would have expected this to be the same plain object I passed in the options
DEFAULT_OPTIONS.renderer
:Definitely unexpected. This should not have the overridden
render
function as an instance property. Also, this is===
towidget.#options.renderer
which is definitely wrong.Now when instantiating a separate widget with no overrides:
I believe that this behavior is a regression from Lodash 3. You can see the difference in behavior between the two here: https://jsfiddle.net/2y7hkzox/
It seems possible that there is a change between the behavior of
baseMergeDeep
. (Lodash 3'slodash/lodash.src.js
Line 2560 in dfbd78f
lodash/src/.internal/baseMergeDeep.ts
Line 74 in c7c70a7
isObject
andisPlainObject
.The author of #5269 stated:
However, I actually wasn't able to find that in the official documentation: https://lodash.com/docs/4.17.15#merge
But, I do agree with the original author that the behavior seems unintended.
The text was updated successfully, but these errors were encountered: