Redux-toolkit: Should updateOne/updateMany support nested updates?

[msutkowski]

As of right now, updateOne and updateMany are only useful if your data has no nesting at all. In the scenario that a user uses a JSON API schema, they'll normally have a structure like { id: 1, type: 'example', attributes: { other: key, another: one } }, depending on how they normalize their data. Should we consider supporting at least one level of nesting with mutable updates? If not, we should update the documentation around these methods.

_Note: Technically it'll process nested updates now, but it'll just replace the nested objects and this may be confusing to users who think immer is doing magic updates here._

[markerikson]

It's an interesting question, but I'd rather not go there for now. Too much potential complexity to figure out how deep updates should work.

That said, the shallow update behavior should probably be documented. Can you add that to the API reference for createEntityAdapter?

[otakustay]

We have previously encountered this issue in out own library, as a solution we provide a customMerge function to something like createEntityAdapter, this can give more extensibility and keep a low complexity at the same time, I'd like to recommend to add a mergeEntity(base: T, incoming: T) option to createEntityAdapter

[markerikson]

I'd be open to seeing some possibilities, but I have concerns about trying to provide a generic merging API. I think there's too many complexities in how that _could_ behave for us to provide a single solution.

Remember that we're not trying to cover _all_ use cases in RTK. We're just trying to hit the 80% common usage scenarios. Users can always write more custom logic themselves.

[tannera]

a customMerge function would be helpful.

[markerikson]

As I said, I'm open to seeing some _specific_ API proposals. But, my inclination atm is that if you need custom behavior, you write your own reducer. It's not _that_ hard :) Especially with Immer available.

[markerikson]

Going to close this for now, since there haven't been any actionable API suggestions. If folks do have specific suggestions on what such an API might look like, please comment with details and we can discuss further.