Apply clone option to target object

TehShrike / deepmerge

A library for deep (recursive) merging of Javascript objects

MIT License

2.76k stars 216 forks source link

Apply clone option to target object #209

Open creativeux opened 4 years ago

creativeux commented 4 years ago

closes #208 closes #186

Added ternary for initializing the destination object based on the clone option.
Added 2 unit tests... 1 to test that target type info is retained, and another to ensure that target memory pointer is maintained when clone is set to false.

TehShrike commented 4 years ago

This looks good. One request – could you add a test that asserts that when merge.all is called with { clone: true }, the first element is mutated/returned?

creativeux commented 4 years ago

could you add a test that asserts that when merge.all is called with { clone: true }, the first element is mutated/returned?

Great call, I hadn't used that entrypoint so didn't think to change it. I made the change, but it required a few more lines to change to make it elegant and aligned with the code style in place. The firstArrayEntry() method is there to avoid chained ternaries which can be confusing to read, and I moved the logic to determine if the destination should be a new object or a target object into a function.

Let me know if you'd like any add'l changes!

RebeccaStevens commented 4 years ago

I like it but I am a little worried about backwards compatibility. As is, this would definitely need to be released as a new major version.

creativeux commented 4 years ago

I like it but I am a little worried about backwards compatibility. As is, this would definitely need to be released as a new major version.

You're probably right. This is an awkward one because it sounds like it is technically a bug fix because the API "lies" to the consumer about how the clone option is applied, but fixing it potentially breaks consumers whose code relies on the bug being there. I'll let you guys duke it out 😉

TehShrike commented 4 years ago

Yup, this would be a breaking change. I'm thinking to pair it with removing the deprecation warning from the clone flag

RebeccaStevens commented 3 years ago

~I've changed my mind on liking this.~ [I'm back to liking it now]

I like the idea behind it but this is definitely a breaking change that I can see a lot of push back happening on if it goes live.

The current implementation of the clone flag makes it so that if set to false, objects will be directly copied over to the resulting merged object. The new behavior in this MR as is makes it so that when the clone flag is false, the target option will be mutated.

These two behaviors are very different and I don't think it would be a good idea to switch from one to the other using the same flag.

The issue with having this behavior on the "clone" flag is that it that it is valid to want to both clone and not mutate the any of the parameters.

I would be best to put this behavior behind a new flag called "mergeWithTarget".

I just made a new issue #212 with my proposal for the clone behavior.

creativeux commented 3 years ago

@RebeccaStevens I lied about how long it would take. My wife started watching The Bachelorette and that was my cue to zone out. Let me know if this addresses the concerns re: clone vs mergeWithTarget.

RebeccaStevens commented 3 years ago

Looks good to me :+1:

RebeccaStevens commented 3 years ago

@creativeux do you want to mark this as closes #186?

creativeux commented 3 years ago

@TehShrike and @RebeccaStevens - I caught a bug with my in-use fork of this where the merge fails in the case that a target is undefined. I pushed a fix and a unit test to ensure that there is always an emtpy object or array to merge into if the target is undefined.