Single Fetch action/loader types with ResponseStub

[ksmithut]

I've been playing around with a new Remix app that has enabled the newly available (unstable) Single Fetch feature. One of the new paradigm shifts is that instead of returning a response, it's recommended to just return data and use the response object that comes into the parameters when you need to change the status code or add headers.

I might be doing something wrong, but the types for ActionFunction and LoaderFunction both have response being ResponseStub | undefined. My understanding is that if I'm using "Single Fetch", the response should always be there. Is there some utility types I should be using? Or is it enough to just do ActionFunctionArgs & { response: ResponseStub }?

[kiliman]

The reason is to prevent a breaking change. Since this is a future API that you opt in, they can't change the function signature directly.

They make note of it here:

remix/packages/remix-server-runtime/routeModules.ts

Line 95 in 7b2fa03

// TODO: (v7) Make this non-optional once single-fetch is the default

However they could do something similar to useLoaderData types by adding future types to tsconfig.json

You must add node_modules/@remix-run/react/future/single-fetch.d.ts to the end of your tsconfig.json's include array to get proper type inference

You can also create your own types that will override the existing ones.

[brophdawg11]

It's worth noting that even with single fetch enabled, response is not provided to resource route loaders because they're just API endpoints and you return the Response directly - there's no need for a stub which is later merged with other stubs to generate a final Response.

Unsure what the best solution is there, of the options I can think off off the top of my head ($) is probably my favorite:

1. leave it as is
2. introduce a ResourceRouteLoaderFunctionArgs type to help differentiate
3. force users to use the response stub
4. pass it and respect it if it's used - but recommend against using it in favor of just setting status/headers on your returned Response instance

[brophdawg11]

Although under the hood that's a bit at odds with the implementation. Response stubs are a feature of data strategy, data strategy is only a thing when you are querying multiple routes (via staticHandler.query) and not a single direct loader/action (staticHandler.queryRoute), and resource routes use queryRoute so they have no access to a dataStrategy at the moment...

[alexanderson1993]

I think there was a suggestion at one point to make resource routes export something entirely different from loader and action - export const resource or export const handler, so they behave more like a proper request/response handler, handling all HTTP verbs, and less like a data strategy implementation.

#7640 (reply in thread)

[brophdawg11]

This would effectively be the same as (2) above, right? Regardless of the name of the export, we'd have to introduce a new ResourceRouteLoaderFunctionArgs type:

type LoaderFunctionArgs = {
  request: Request,
  params: Params,
  context: AppContext,
  response: ResponseStub
}

type ResourceRouteLoaderFunctionArgs = {
  request: Request,
  params: Params,
  context: AppContext,
}

[alexanderson1993]

Ah, yes. That is true.