Shouldn't assign-deep mutate dates? about assign-deep HOT 5 CLOSED

What do you think? I can process with the pull request if you agree.

I agree we should support what you expected, but I think a better approach would allow a customizer function to be passed as the last argument so that the user can decide whether or not they want to retain the reference. That would be more consistent with assign behavior. Does that sound okay?

from assign-deep.

For me "customizer function" sounds a bit strange... How will it work? If it would process each single property from the passed objects (and decide whether or not to clone it) this will slow down the initial implementation. And is the assign you mentioned corresponds to Object.assign?

It is hard to tell whether your library should do this by default. Yes, Object.assign mutates all property values, it's okay for your library to keep the same behavior. In this case, my issue just turns more to a kind of a question :)

from assign-deep.

Actually, after looking at this again, this shouldn't clone, it should only "assign". I think both values in your example should be true, not false.

from assign-deep.

@jonschlinkert, my very base case is that as a user, I expected assignDeep to behave like clone. In other words, make a 100% clone of the object without mutating any of its properties. If that isn't true, that's okay, however, then I need another library for my case :) Feel free to close this issue.

from assign-deep.

got it, maybe take a look at https://github.com/jonschlinkert/merge-deep, perhaps that's closer to what you need.

from assign-deep.