Custom request predicate function

[kettanaito]

Scope

Adds a new behavior

Compatibility

• This is a breaking change

Feature description

Right now, the predicate part of the request handler is usually a string or a RegExp (in some cases, a more complex data structure, like a TypedDocumentNode for GraphQL operations). That's handy but sometimes developers want to have completely custom predicates. For example:

• Only intercept requests with a particular search parameter;
• Only intercept requests with a certain header/body.

We encourage implementing Custom request predicate via the higher-order resolver function. While that's flexible, it's a bit upside-down from the request handler's perspective since the resolver is run after the predicate phase.

Proposal

Expose a ({ request: Request }) => boolean function as the accepted value for the predicate argument of any request handler.

http.get(({ request }) => request.url.includes('foo'), resolver)

The previously accepted predicate values remain, this is an additive feature.

This will allow for more streamlined request predicates, even support reusing them separately from the response resolver logic.

http.post(async ({ request, ...resolverArgs }) => {
  // Must clone the request, lest its body stream will be
  // locked in the response resolver.
  const body = await request.clone().json()
  return body.property === 'value'
}, resolver)

Internal changes

In order to expose as much request info as possible, we'd have to move the extendResolverArgs() phase before the call to the predicate() method of the RequestHandler. That shouldn't be a big deal as both existing handlers extend the resolver arguments with the data derived from the parsedResult.