Mocking Mutations
Manage change by updating the store in mutation resolvers.
note
This page assumes you know how to setup your app to use the Kimera executable schema. If you don't, check out the Setup section of the docs.
Let's start with a schema that has createRocket
mutation.
The createRocket
mutation takes a name
and a model
for the new rocket, and returns the complete list of rockets, including the new one if it's successful.
mutationResolversFn
example
In order to pass this new mutation, we'll have to do it as part of the return object of a new getExecutableSchema
option: mutationResolversFn
.
To define a resolver for a mutation with Kimera, we need use a new getExecutableSchema
option: the mutationResolversFn
function.
mutationResolversFn
needs to return an object with all mutation resolvers we want to define.
mutationResolversFn
API
Kimera passes two arguments to mutationResolversFn
:
store
: This is an object which holds all of the mocks for our schema. It defines two methods:store.get(path = '')
: Theget
method will accept an optionalpath
string, and return the mocked value stored at that specific path.store.update(path, updateValue)
: Theupdate
method will update the value at the suppliedpath
with the new value. If the updated value is an object, the new value will be deeply merged over the existing value.
buildMocks('TypeName', scenario)
: This is a function mocks a specific type using existing mock providers, and optionally, a custom scenario that we can provide at execution.
Next we'll look at several examples of using these arguments.
store
and buildMocks
examples
Starting with some form of the following schema:
Here are a few ways to affect the mocked data in a mutation:
note
For an example of using mutations, check out the server example in the Kimera Github repository.