Infer resolver's response body type from return type of given fetcher function

[bennettdams]

Hey!

I would like to keep in sync what my fetcher functions return and what I return from my resolvers (as response body). So when the type of the fetcher function changes, the MSW resolvers will remember you to also change that response body (via a TypeScript error 😅).

Maybe I missed something in the docs, but as far as I can tell, when defining resolvers, their response body cannot be inferred out of the box (with MSW v0.39.2).

I thought about using the return type of my real fetcher function to specify the resolver's generic for the response body.
Something like this:

// fetcher function
export async function fetchMyData(): Promise<MyData> {
  ...
}

// helper type for the response result
type ResponseResult<TFunction extends (...args: any[]) => Promise<unknown>> =
  Awaited<ReturnType<TFunction>>;

// handlers
export const handlers = [
  // use the response result here for the generic
  rest.get<null, any, ResponseResult<typeof fetchMyData>>(
    `${apiPrefix}/my-data`,
    (req, res, ctx) => {
      // `ctx.json` is now type-safe (inferred to `MyData` from `fetchMyData`)
      return res(ctx.json({
        a: 123
      }));
    }
  ),
];

A few questions:

• Is there an easier way to do this?
• If not, should there be an easier way as part of the library? Theoretically it should be possible to give the resolver functions (like rest.get) your fetcher function type (typeof fetchMyData) and MSW inferrs the whole type, similar to how e.g. "React Query" does it.
• Does someone know how to avoid any for the function args ((...args: any[]))?
• How to avoid any for the path params of the rest.get generic? It does not allow null like the request body generic does.

[kettanaito]

Hey, @bennettdams. Thanks for raising this.

I believe you can achieve what you want simply by providing the MyData type as the ResponseBodyType generic to REST API request handlers:

interface MyData {
  username: string
}

function fetcher(): Promise<MyData> {}

rest.post<never, MyData>('/resource', (req, res, ctx) => {
  return res(ctx.json({ username: 'octocat' }))
})

Also note that the generic signature is RequestBodyType, ResponseBodyType:

msw/src/rest.ts

Lines 12 to 16 in c30bcd5

	return <
	RequestBodyType extends DefaultBodyType = DefaultBodyType,
	ResponseBodyType extends DefaultBodyType = DefaultBodyType,
	PathType extends Path = Path,
	>(

The third generic ParamsType is purely internal and you should not really specify it.

[bennettdams]

Hey, thanks for your answer.

simply by providing the MyData type

I know I can do that, but instead I would like to use the return value of my fetcher function. That way, I don't have to change the type in two places, but rather only rely on the fetcher function as the source of truth. That's what I meant with "...the MSW resolvers will remember you to also change that response body (via a TypeScript error 😅).", which will kick in when you change your fetcher function.

And additionally, my point still stands: I think it would be nice if the resolvers would just accept such a fetcher function and infer the request body and response body on their own.

Also note that the generic signature is RequestBodyType, ResponseBodyType:

That is not true, the current release (v0.39.2) has the following signature:

post: <RequestBodyType_3 extends DefaultRequestBody = DefaultRequestBody, Params_3 extends PathParams = PathParams, ResponseBody_3 extends DefaultRequestBody = DefaultRequestBody>(path: Path, resolver: ResponseResolver<RestRequest<RequestBodyType_3, Params_3>, RestContext, ResponseBody_3>) => RestHandler<import("./handlers/RequestHandler").MockedRequest<DefaultRequestBody>>;

The path params are the second generic, so you have to set them if you want to set the response body generic.

What you have posted is an unreleased change where the generic for the path params and response body have swapped places:

...so I guess I just wait for the next release for the path param topic 😅

[kettanaito]

You do establish a single source of truth—the MyData type. Both your fetcher function and your request handler now have the response body annotated as per MyData. That's the way I'd recommend doing it. Extracting types is almost always a bad idea in the regular development land. I don't see any benefit of extracting the data type from the return type of your fetcher given you're likely to use fetcher as a generic anyway:

function fetcher(): Promise<MyData>

// as opposed to

function fetcher(): Promise<{ username: string }>

I always recommend extracting data types like this. It simply makes your TypeScript code more reliable and types more reusable (you may depend on MyData in other places, extracting it from the fetcher will always be lengthy).

That is not true, the current release (v0.39.2) has the following signature:

Oh, my bad. You're right, the 0.40.0 hasn't been released yet.

[bennettdams]

I feel like I was not clear enough with what I have asked initially.

I always recommend extracting data types like this.

I totally agree and as you can see in my post, all my fetcher functions are like this already. All of them use a specific type for their response, which is the type of the data (like MyData):

export async function fetchMyData(): Promise<MyData> { ... }

I can reuse MyData also for e.g. the MSW resolvers, all good.

As far as I understand, what you're saying is that I probably should use explicit return types for my fetcher functions anyways, right?

Something like:

export type ApiReturnMyData = MyData

export async function fetchMyData(): Promise<ApiReturnMyData> { ... }

..and I agree that this is more explicit, but you could also argue that it brings unnecessary "overhead", right? I totally use MyData in other places already, but I never need the return type of the fetcher function somewhere else - I just need it for the MSW resolvers.
BTW: In my case, the fetcher functions have some utility built in, so they never return the data directly, but rather a utility type (HttpResponse) with the data type as generic (HttpResponse<MyData>). So just using the data type as a return doesn't make sense.

Still, I think this is a valid solution for now, as I can use the return type in the MSW resolvers that way as well.

I don't see any benefit of extracting the data type from the return type of your fetcher

I agree, but my additional question was about inferring the whole fetcher function, which would eliminate the need to set this explicit response body (and request body) type, similar to how React Query does it.

[kettanaito]

I recommend going for explicit returns 200% of the time. You need to be super careful with inferred types. You can't go wrong with explicitness! I'd even go as far as to advise you to enforce strict return types via eslint.

If you absolutely have no other way, you can use the extractor type as you've mentioned in the question to operate on typeof fetcher. I still won't recommend that.