Deferring specific mutations until user needed.

[saivanji]

I have visual editor feature in my application where every change of a form field triggers a mutation.

I would like to implement "Save/Cancel" feature where user will make desired changes in the editor but instead of sending mutation server request, we pause it and apply optimistic update result with cache update so the components will be populated instantly with new data. Next when user will hit "Save" button we will send all pending mutations at once.

I guess that can be achieved with custom exchange but I'm stuck at getting access to cache instance inside of my exchange:

import { pipe, filter, map, merge } from "wonka"
import * as optimistic from "./optimistic"
import * as updates from "./updates"

export default ({ client, forward }) => {
  return (ops$) => {
    return merge([
      pipe(ops$, filter(shouldDefer), map(op => {
        // How to access `cache` instance here? Since I need to maintain the logic of cache
        // updates applied in graphcache exchange.

        return optimisticUpdate(op, optimistic)
      })),
      pipe(ops$, filter(shouldNotDefer), forward)
    ])
  }
}

Also is that's the best way of solving that problem or it can be done differently?

[frederikhors]

Can you just use js framework specific feature instead of urql?

[saivanji]

Yep, I was considering that. But the thing is that all of the editor state is located in urql's cache so I need to duplicate state handling logic in order to implement it on the application side. I might do that as a last resort if the approach above will not work.

[kitten]

I believe your issue is similar to this: #1083

Ultimately if you control the schema we can assume that you can alter it maybe to serve this use-case.

An exchange after Graphcache can see all the mutations it’s trying to send. So if you already have optimistic mutations in place then those will be applied but each will also be sent as an actual mutation onwards in the exchange pipeline.

It’s possible to write a custom exchange that groups all mutations for editing purposes and send them off on a specific signal (or denounce). A specific signal could be an neun flag in the mutation or a boolean flag (or even just a context property) that only the client cares about.

This isn’t quite trivial to write but then again the usage also isn’t trivial.

[saivanji]

Agree, the issue isn't trivial. I think it would be simpler to have that logic on the application side as @frederikhors suggested.

[kitten]

We're looking into some kind of batching mutation solution, but that being said, this logic will always end up being very application-specific as it relates to your specific schema and use-case, so either way, even if we find a nice abstraction for it, this abstraction could in theory just have a very nieche usage of just a couple of users. So I would still suggest you to look into the exchange linked above to some extent.

We can also help to get this logic right, as it's basically similar to what you already started drafting above, so I don't believe you were even far off, except that the cacheExchange from Graphcache, as all other exchanges, is isolated from other exchanges.