feature idea: optimistic response with debounced server-calls mutation

Would it be possible to have the optimistic response update immediately, while the actual request to the graphql server would be debounced?

Such that, if the first debounced mutation sends its request and the user makes another change, then when the response from the first mutation arrives it still uses the newer optimistic response, until the second mutation response resolves the end result.

I have simple debounce working, but the optimistic response isn’t used until the debounce expires, and if i remove the debounce then it makes a mutation per input event.

import React from 'react';
import debounce from 'lodash/debounce';
import { gql, graphql } from 'react-apollo';
import { View, TextInput } from 'react-native';

const Note = ({ content, updateDailynote }) =>
  <View>
    <TextInput
      value={content}
      onChangeText={updateDailynote}
    />
  </View>;

const updateDailynote = graphql(
  gql`
    mutation updateDailynote($input: UpdateDailynoteInput!) {
      updateDailynote(input: $input) {
        __typename
        dailynote {
          __typename
          nodeId
          content
          dailynoteId
        }
      }
    }
  `,
  { name: 'updateDailynote' },
);

export default updateDailynote(
  ({ nodeId, content, dailynoteId, updateDailynote }) =>
    <Note
      key={nodeId}
      content={content}
      updateDailynote={debounce(
        content =>
          updateDailynote({
            variables: {
              input: {
                nodeId,
                dailynotePatch: { content },
              },
            },
            optimisticResponse: {
              __typename: 'Mutation',
              updateDailynote: {
                __typename: 'UpdateDailynotePayload',
                dailynote: {
                  __typename: 'Dailynote',
                  nodeId,
                  content,
                  dailynoteId,
                },
              },
            },
          }),
        500,
      )}
    />,
);

[jbaxleyiii]

@msand thank you for the great responses! I really appreciate the thoroughness of them. I will close this issue, but as a heads up, we are working on a new way to compose a client which would make this possible on the client level if desired. I’ll ping you when it is ready if you want to take a stab at writing a package for debouncing!

[jbaxleyiii]

@msand I wonder if this is the best approach? Since you are binding direct user interaction, it seems to me using a combination of local component state + a delayed mutation would be the better option? It will be more performant as it doesn’t go through any Apollo store actions, nor would rerender the graphql wrapper.

When possible, I’d like to steer clear of debouncing in library code since it is pretty much always tied to direct UI piping which is the better place to implement the delay