Break the object reference of the result returned by the base query/mutation
luii opened this issue · 3 comments
Which @ngneat/query-* package(s) are the source of the bug?
query
Is this a regression?
No
Description
Angular's computed signals seem memoize the object references, thus maybe we should break the reference to the old (but same) object returned by the query observer before piping it through the shareReplay
operator, this would universally apply to all of the signal getter. I used a much simpler reproduction and without @ngneat/query
to illustrate the problem that even without it applies.
Please provide a link to a minimal reproduction of the bug
https://stackblitz.com/edit/stackblitz-starters-vkwvv1?file=src%2Fmain.ts
Please provide the exception or error you saw
Not an actual error but once the initial value (e.g. the synchronous result is returned by the query) the signal itself still updates but not a computed signal.
Please provide the environment you discovered this bug in
No response
Anything else?
See #135 for more information.
Do you want to create a pull request?
No
Start a new pull request in StackBlitz Codeflow.
I was originally looking to fix this by placing map operator before the shareReplay in base-query.ts
and mutation.ts
that essentially did this:
map(result => ({...result}))
However, I believe this creates a shallow copy and any computed calls evaluating the nested data would run into the same memoization problem. We would probably need a deep clone here to prevent this right? If so, I wanted to see what you or the other maintainers of this repo would like to use to do so. Typically I would pull in the cloneDeep function from lodash, but I don't want to add external libraries unless needed and OK with the repo maintainers. There is also the good ole'
JSON.parse(JSON.stringify(obj));
But this can cause issues with data loss when the data does not have a JSON representation, such as Dates.
If I am completely missing the mark here, please let me know. I am not so proud that I cannot admit I am a bit out of my wheelhouse when trying to understand this problem in the context of the entire library and how it works.
The response should be immutable. Closing the issue.