Wrapping client mutate function

Feature Request

Currently, when calling mutate functions users will need to pass generated optimistic response and also supply global cache updates. UX of that approach is quite restrictive and prevents developers from taking things even further.

client.mutate({ 
     ...devOptions, 
     *optimisticResponse: createOptimisticResponse()*
     update: updateFn
})

Proposal

Provide wrapper for client.mutate that will provide extra capabilities:

Variant 1

Example parameters for wrapped mutate function:

client.mutate(...devOptions, 
  // Ability to control how offline state is reported
  offlineStrategy: 'failWhenOffline', 
  // Add ability to update Query cache automatically
  updateQuery: "getItems",
  // Adds automatic optimistic response based on payload
  generateOptimisticResponse: "getItems")
}

Variant 2

client.mutate(...devOptions,
  // Supplies argument that will be used to build 
  // Optimistic response and query Updates
  // Devs will be able to override them by 
  // supplying original parameters to function. 
  affectedQueries: ["getItems"]
  // Many other arguments possible
}

Function internally can

• Check if we are offline online
• For offline it will save changes locally
• Register update functions that will be triggered to see optimistic responses.
• Allow providing sensible defaults and better support for offline that is not limited to Apollo Link/Apollo client API.

Pros/Cons

Pros

Doing this will give us many benefits:

• Awesome UX and Offline support out of the box.
• Simplify entire implementation (no holding mutations etc.)
• Ability to work with other clients depending on the community interest (not only Apollo)
• Ability to autogenerate cache updates (update fn) if dev did not supply them
• Ability to autogenerate optimisticReponse if it was not supplied
• Ability to supply extra parameters. For example, we can check if the client is offline and then return result instantly

Cons

• A custom client without the ability to reuse links inside Offline Link will no longer be sufficient to integrate that with other projects.

Alternatives

Keep existing implementation without the wrapper and provide a toolbox that will generate some parameters:

const offlineArguments = offlineHelper({affectedQueries}
client.mutate(...devOptions, ...offlineArguments)

[ntziolis]

Totally see the usefulness of this. that said, given the fluid state of graphql ecosystem I would wait a little longer before going down the path of a custom client while still providing a way to reduce boilerplate code by:

• Exposing the offlineHelper method as you described for people that wanne do it manually
• as well as add an additional medhod to the client ala client.mutateWithOffline() that internally calls the above helper method for people that wanne reduce boilerplate

Any future refactoring necessary for users of this lib would be pretty straight forward should you decide to go down the path fop a custom client lateron.

[evelant]

I also think @ntziolis has a good suggestion. Exposing an optional method to reduce boilerplate sounds great.