Canceling scheduled optimistic mutations

[codazzo]

Hi! I'm bringing some more feedback around the offline scenario in hope you find this useful. This time it's an idea more than a bug report :)

For reference, I'm developing a native app which will run on mobile devices. These devices are expected to get offline for stretches of time during which users can create entities, let's call them "recommendations".

For this purpose I'm using an optimistic mutation which creates an entity with a randomly assigned ID.

As of #1073 we can successfully create a number of recommendations while offline, which get applied when the device gets back online. Now imagine the following scenario: a user creates two recommendations, then deletes one of them, all the time while the device is offline. When the device gets back online, this currently triggers the following mutations

createRecommendation(payload1)
createRecommendation(payload2)
deleteRecommendation(temporaryID1)

The last one fails because we don't know the entity's actual ID and the server rejects temporaryID1.

One way to support this use case would be to allow users to cancel scheduled optimistic mutations. I can't think of an obvious API and it's admittedly a bit of an edge case but I thought I'd bring it up for discussion. Do you think it's a generic enough scenario that's worth supporting?

As a workaround I'm hiding the UI elements that trigger entity deletion while the entity has a temporary ID (ie. it has not been synced with the server).

[kitten]

Currently we're purposefully not supporting this. Because if there was an API for this arguably it's UI state on which mutations are pending and which should be pending.

I do also see the perspective of "optimising" mutations, but the question is whether that's something you'd rather do in the transport by adding some kind of debounce + filter.

[kitten]

So to clarify, long snippet incoming here, but I wanted to post what I meant when I said it's possible to filter mutations. We can make an exchange that debounces all mutations and then filters the ones that are about to be sent out. This can go in front of the fetchExchang and would look something like this, primitively:

import { Kind, OperationDefinitionNode, DocumentNode } from 'graphql';
import { Exchange } from '@urql/core';
import { pipe, fromArray, merge, mergeMap, buffer, share, filter, debounce } from 'wonka';

const getMainOperation = (doc: DocumentNode) => {
  for (let i = 0; i < doc.definitions.length; i++) {
    if (doc.definitions[i].kind === Kind.OPERATION_DEFINITION) {
      return doc.definitions[i] as OperationDefinitionNode;
    }
  }

  return (undefined as never);
};

export const sanitizeMutationsExchange: Exchange = ({ forward }) => ops$ => {
  const sharedOps$ = share(ops$);
  const mutations$ = pipe(
    sharedOps$,
    filter(op => op.operationName === 'mutation')
  );

  const bufferedMutations$ = pipe(
    mutations$,
    buffer(pipe(
      mutations$,
      debounce(() => 100)
    )),
  );

  const filteredMutations$ = pipe(
    bufferedMutations$,
    mergeMap(buffer => {
      for (let index = 0; index < buffer.length; index++) {
        const operation = buffer[index];
        const query = getMainOperation(operation.query);
        const deletion = query.selectionSet.selections
          .find(x => x.kind === Kind.FIELD && x.name.value === 'deleteNode');

        if (deletion) {
          for (let i = 0; i < index; i++) {
            const query = getMainOperation(buffer[i].query);
            const creation = query.selectionSet.selections.find(x => (
              x.kind === Kind.FIELD &&
              x.name.value === 'createNode'
              // TODO: Try to match this with the deletion
            ));
            if (creation) {
              buffer.splice(i, 1);
              buffer.splice(index, 1);
              index--;
              break;
            }
          }
        }
      }

      return fromArray(buffer);
    })
  );

  return forward(merge([
    filteredMutations$,
    pipe(
      sharedOps$,
      filter(op => op.operationName !== 'mutation')
    )
  ]));
};

Obviously it'd still force you to correlate creations to deletions, but it is still possible to engage with this. Since the offlineExchange also sends mutations that are retried through the entire exchange pipeline there are more tricks that may work here.

[codazzo]

I wanted to post what I meant when I said it's possible to filter mutations

Definitely helped to look at a code snippet for this. It's a better solution than an "optimistic mutations control" API. Thanks for sharing! 🏅

[kitten]

I think I forgot in the above to call client.dispatchOperation with appropriate teardown operations, but it still conveys the gist of it 😅

[frederikhors]

@kitten is this going to become an official exchange or part of official codebase?

[kitten]

Probably not, no. This is really on the verge of catering for a specific API and mechanisms in a specific app. In most cases, it’s more advisable to block optimistic mutations that operate on other optimistic types, because we can’t identify optimistic data easily that has been created by users