I just had a situation where it would be useful to read variables passed to a mutation from its update function. The official TypeScript definitions state:
export type MutationUpdaterFunction<
TData,
TVariables,
TContext,
TCache extends ApolloCache<any>
> = (
cache: TCache,
result: Omit<FetchResult<TData>, 'context'>,
options: {
context?: TContext,
variables?: TVariables,
},
) => void;
https://github.com/apollographql/apollo-client/blob/main/src/core/types.ts#L170-L182
My use case is that I wanted to create a hook that uses MySharedMutation.use() under the hood, passing it the update function, so that users of that custom hook do not need to think how to update cache for that specific mutation.
let useMySharedMutation = MySharedMutation.use(~update=updateLogic)
/// later, somewhere else...
useMySharedMutation(/* options, without the need to specify `update` logic*/ { /*variables*/ })
Do you think it makes sense to add options param to ReScript bindings as well? I'm asking because it would be a breaking change in the sense that all users of the update param would need to update their functions passed to update to include the third param ~options.
I just had a situation where it would be useful to read variables passed to a mutation from its
updatefunction. The official TypeScript definitions state:https://github.com/apollographql/apollo-client/blob/main/src/core/types.ts#L170-L182
My use case is that I wanted to create a hook that uses
MySharedMutation.use()under the hood, passing it theupdatefunction, so that users of that custom hook do not need to think how to update cache for that specific mutation.Do you think it makes sense to add
optionsparam to ReScript bindings as well? I'm asking because it would be a breaking change in the sense that all users of theupdateparam would need to update their functions passed toupdateto include the third param~options.