Mutation scopes - Next steps

[saravanak]

As per the implementation for Scoped Mutations, there is a reasoning as to why the Scope is a Map instead of a string:

If set, mutations in the same scope will be guaranteed to run in serial. The object notation enables to later allow for different scope behaviours. For example, a scope could be implemented to abort previously running mutations when a new mutation is added, and kick of the last mutation immediately. It could also get a takeLatest kind of behaviour where mutations still run serially, but in-between mutations get discarded. In the first iteration, scopes will only get the default behaviour of queuing up mutations and starting the next one in the scope when they are finished.

I think this ties in nicely with the modifiers feature set of ember-concurrency(EC). It'd be pretty awesome if we added the entire feature set here. Here are some questions that expose my limited understanding of the internals of query

1. Why don't we have scoped queries?
   Usecase: Consider a email search query on the register page to show if the email is already taken. Since this is a GET request most probably, it would get implemented as a Query rather than a Mutation. But providing it a scope, along with TakeLatest semantics as noted above, will reduce the number of calls to the backend. Since a Query takes in a queryKey, at the moment, this is sent across as individual request without the opportunity to batch. I think that extending scopes to queries (as against the current support to only mutations) to bring the order semantics would be a more usable

2. Cancelling mutations
   We might need to have the ability to cancel existing requests backed by a Mutation to implement the discarding ongoing requests use case. I see there is a direct API for cancelling queries . Not sure if the mutations are cancellable. Read through the code; and the abort signal is only being created by the Query infrastructure

Basically, I want to open the discussion about what it entails to implement the next steps on the scoping feature and the overall technical directions towards the same so it could be easy for me to contribute back.

cc @TkDodo as he raised the original RFC

[TkDodo]

But providing it a scope, along with TakeLatest semantics as noted above, will reduce the number of calls to the backend.

queries should be idempotent and can be cancelled, so takeLatest here is really just fire each one as soon as possible and cancel the previous ones.

Not sure if the mutations are cancellable

they are not, because they can trigger side-effects on the server that we cannot stop once they have started (yet this is what users will likely expect with cancellation).

[saravanak]

queries should be idempotent and can be cancelled, so takeLatest here is really just fire each one as soon as possible and cancel the previous ones.

Ok, so what you are suggesting is that the existing modifiers of EmberConcurrency can actually be implemented as custom hooks, wrapping useQuery, and hence there is no need for a change here?