startMocking(requestHandlers)
mockServiceWorker.js
to your public folder by running yarn msw init path/to/your/public/
. Automatically works in Node.JS.requestHandlers: Array<msw.RequestHandler>
- a list of mocked request handlers. Can use standard MSW rest/graphql handlers. We recommend using strongly typed GraphQL mocks using createGraphqlHandler
below.msw.SetupWorkerApi | msw.SetupServerApi
mocking.use(...requestHandlers)
. These can be reset with mocking.resetHandlers()
.createGraphqlHandler(options: Options)
Options#mask?: string | RegExp
- which urls to handle. Defaults to '*/api/graphql'
.resolvers: Resolvers
- graphql resolvers as returned by createResolvers
below.schema: GraphQLSchema
- graphql schema for mock api.msw.RequestHandler
- should be passed to startMocking()
above.fetch
fetch
function that ignores its mocking handlers. The graphql handler passes this fetch
function to resolvers using the GraphQL context argument. Example:createResolvers(baseResolvers)
createGraphqlHandler
. Supports standard field and type resolvers.baseResolvers: Resolvers
- the initial mocked resolvers.#add(resolvers: Resolvers)
- adds (and overrides) mocked resolvers. Useful to test edge cases in E2E test.#reset()
- resets resolvers to the initial resolvers passed to createResolvers()
createStore<Data>(initializer)
afterEach()
.initializer: () => Data
- a function which creates the mock data and returns as an object.initalizer
function, with one additional property:$reset(): void
- Resets the store to the initial state.initializer
function. The initializer
function is lazily invoked the first time a property is accessed.factory<Type>(initializer)
Type
generic can be specified explicitly based on types from the GraphQL schema to give a better developer experience.initializer
- initializer object which matches the shape of Type
.this
and as the first parameter.initializer.$traits
- map of traits which can be used when generating objects.Note: Properties are assigned in the order they are defined in the rootinitializer
object (even if traits or overrides have another order). Example:1factory({2a: 5,3b() {4return this.a5},6c() {7return this.b8},910$traits: {11changed: {12c: 7,13// b will always return undefined since c is assigned after b.14b() {15return this.c16},17},18},19})Copied!
(...data: Array<string | object>) => Type
#list(count: number, ...data: Array<string | object>) => Array<Type>
count
objects. Supports traits and overrides.title()
faker.lorem.words()
.slugify(field)
simpleFactory(initializerFn)
faker
startMocking
when process.env.API_MOCKS === 'true'
. Then Webpack is able to remove it from the bundle in production builds.store
is not used in production builds, but it won't remove the code since createStore
could have some side-effect.package.json
in the mocking folder that includes { sideEffects: false }
. However, that would remove the startMocking()
call, which is a side effect we want (at least in development).startMocking
in its own file (e.g. mocks/index.ts
) and mark that as the only file with side effects: