Supports async response transformers

[kettanaito]

Changes

• Now it's possible to create async response transformers.
• Exports compose function publicly to compose multiple standard response transformers as a part of a custom response transformer.
• Adds browser integration tests for an async response transformer.
• Handles response calls as potentially async in unit tests.
• Aligns unit tests to be shallow (drops describe blocks).

GitHub

• Closes Support asynchronous response transformers #465

Roadmap

• Annotate compose properly (infer function type, set return type)

[kettanaito]

I find it extremely readable to await the transformer upon invocation, as opposed to drilling asynchronicity all the way down to the response composition tree.

[kettanaito]

This is an example of a custom jpeg response transformer that appends a given Base64 image to the mocked response. It utilizes newly exported compose function, as well as the ability to make the transformer async.

[timdeschryver]

Don't we have to await somewhere (I think in compose)?

My thoughts:
ResponseTransformer can now be a promise and is a parameter (defaultTransformers) for createResponseComposition. This parameter is used to build the resolvedTransformers, which is passed to the compose method. So, when we're in compose, we still have the promise, and we're not awaiting its result.

(I could be wrong tho, I didn't test it)

[kettanaito]

Thanks for the feedback, @timdeschryver.

Don't we have to await somewhere (I think in compose)?

Not with the current implementation. We allow response transformer to be async, but it must be awaited within the response resolver (which is already supported as async). That way the list of transformers that we supply to compose consists of already resolved transformer functions and there's no need to await in the compose itself:

async (req, res, ctx) => {
  // `res` will get the resolved value of `customTransformer`, not the Promise
  return res(await customTransformer())
}

ResponseTransformer can now be a promise and is a parameter (defaultTransformers) for createResponseComposition. This parameter is used to build the resolvedTransformers, which is passed to the compose method.

That's a great point. I'll add a test that ensures that async transformer passed to the custom response composition function still executes properly 👍

[kettanaito]

What do you think about this extension to the compose function?

msw/src/utils/internal/compose.ts

Lines 5 to 17 in d526e8e

	export function compose(...funcs: Array<(...args: any[]) => any>) {
	return funcs.reduce((f, g) => {
	return (...args: any[]) => {
	const res = g(...args)
	if (res instanceof Promise) {
	return Promise.resolve(res).then(f)
	}
	return f(res)
	}
	})
	}

I didn't want to make it always return a Promise, which would ruin a synchronous execution. At the same time if any of the functions returns a Promise the compose returns a Promise accordingly.

I only wish we could still annotate compose so it understands that return signature.

I've also added an integration test for an async response transformer as the value of defaultTransformers of a custom response.

[timdeschryver]

LGTM, nice @kettanaito!

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 5ec66d2:

Sandbox	Source
MSW React	Configuration

[kettanaito]

Experiencing some TS issues during the compilation of an Angular project as a part of smoke tests.

[timdeschryver]

@kettanaito this could be due to miss matching typescript versions.
I'm going to upgrade the angular example to the new angular version, which also supports TS 4.x.

[kettanaito]

This is amazing, @timdeschryver! Thank you for figuring that out. I'll review your Angular pull request.

[timdeschryver]

No problem! It was an error that I've had seen before 😅