[docs] clarify difference between mutateAsync and requestAsync

[RohovDmytro]

[docs] clarify difference between mutateAsync and requestAsync

[RohovDmytro]

@ryanashcraft thanks a lot. I'll think a little bit more.

@MrNice this sounds oversimplified, but this one I totally get it :)

[ryanashcraft]

Thanks for the kinds words. 😊 Yeah I admit this is confusing and there's things to be done here to make it less so – from docs/runtime warnings/different behaviors.

Let me quickly outline a few of the motivations behind the differences:

• every "entities" collection are safe boundaries for this problem. simultaneous requests for different entities should never be a problem.
• requests should be non-destructive, therefore it's OK to let the latest request to complete "win" because order shouldn't matter. request update functions should be written in a safe way that behaves correctly regardless of the order in which the requests return.
• mutations are destructive, therefore you run into problems when you issue multiple mutations for the same entity. redux-query doesn't have a built-in mechanism for handling conflicts when this happens. it actually discourages this behavior (in a horrible, silent way) by using the same entities state you had when you dispatched mutateAsync. one possible solution we've discussed for this problem is to queue mutations based on the entities that they update.

Let me know if you have any questions or if that doesn't make sense. I do plan on addressing some of these aforementioned problems in the future…

[MrNice]

@rogovdm I think about requests as data reads from network and mutations as data writes to network, similarly to action Creators being state writes and selectors being state reads. I hope that helps!