fix(core): fix freezing of source object after mapping #468
Conversation
Prevent freezing of the given source object as side effect of map(Array)/mutate(Array). Create shallow copy of source before freezing it and using the frozen copy for the remaining mapping process. ISSUES CLOSED: nartc#467
|
Let's just remove the |
Yes freezing the source object as a side effect, causes issues if you try to store an entity with an ORM library after it was mapped (e.g. to a DTO object). At least when using typeorm, since it adds auto-generated I also found that the way the source object was frozen previously (and still in this PR) is shallow, meaning that side-effects in custom mapping configurations and before/after map hooks are still possible, since child objects aren't frozen. To prevent structural side-effects completely we'd have to deep freeze the source object (e.g. by utilising something like lodashs For now I will adjust my PR so that the source won't be frozen. I don't think that this cause many issues, since side-effects will only happen in user code. If you point me to a good place in the docs I could add a disclaimer that the changes to the source object in user code will "persist". |
|
Kudos, SonarCloud Quality Gate passed!
|
|
@LennartH that would work. In the future we can utilize https://developer.mozilla.org/en-US/docs/Web/API/structuredClone. It landed in Node v17 but hasn't been back ported. As soon as we're on a NodeJS version that supports it, we can start using it. I also plan on implementing "Type as Contracts" aka Validations against the metadata for incoming Source and outgoing Destination objects so we should be safe that way instead of freezing the objects. Running CI now. Will merge as long as it's green. Thank you for your contributions |
Prevent freezing of the given source object as side effect of map(Array)/mutate(Array).
Create shallow copy of source before freezing it and using the frozen copy for the remaining
mapping process.
ISSUES CLOSED: #467