Type of loader/action is not inferred correctly when using redirect

[Marcdj-02]

With the following loader function:

type LoaderData = {
  content: string;
}

export async function loader({ params, request }: LoaderFunctionArgs) {
  if (hasNoAccess) {
    return redirect('/login');
  }

  return json<LoaderData>({ content: 'Hello World' });
}

I would expect the return type of the loader to be:

Promise<TypedResponse<LoaderData>>

But in this case it is:

Promise<Response>

This means that the useLoaderData<typeof loader> cannot infer the types of the loaderData.

Anyone got any suggestions?

[machour]

Hey,

First thing first, you shouldn't need to define/use LoaderData, Remix will be able to infer that for you.

Your loader is currently returning either a redirection, or a json object, so it would be wrong for inference to lie to you and say you only get a LoaderData from your loader.

What you can do instead, is change return redirect('/login') to throw redirect('/login') which will do the same thing. This way, your loader only returns the struct, and inference will work as expected:

export async function loader({ params, request }: LoaderFunctionArgs) {
  if (hasNoAccess) {
    throw redirect('/login');
  }

  return json({ content: 'Hello World' });
}

[Marcdj-02]

First of all. Thanks for replying.

Regarding your first point, the types are not inferred right if I don't specify LoaderData in the following case:

export async function loader({ params, request }: LoaderFunctionArgs) {
  if(hasNoAccess) {
    return json({});
  }

  return json({ content: 'Hello world' });
}

This will result in a return type of

Promise<TypedResponse<{}>>

Instead I expect:

Promise<TypedResponse<{ content?: string }>>

Secondly, I am aware of the throw redirect() instead of return redirect() option, but this calls for the developer to be aware of this (If not the loaderData is just given a type of 'any'). Maybe we could make it more intuitive by changing the return type of the loader which would then reflect that it could be a json response or a redirect response. This then can be caught in the useLoaderData's type inference?

For example:

Promise<TypedResponse<LoaderData> | RedirectResponse>

Then the useLoaderData hook can just use the TypedResponse and disregard the RedirectResponse

[machour]

What remix version are you using?

I'm using 1.16.0 and seeing this behavior:

✅ inference of with json() & redirect()

✅ inference of with 2 non-empty json()

🐛 inference is broken if you return an empty object

Also, could you possibly be mixing imports and importing json or useLoaderData from react-router instead of @remix-run/xxx ?

[machour]

Two side notes:

• feat: simplified types for useLoaderData, useActionData, useFetcher, SerializeFrom #6449 (available in v0.0.0-nightly-d56574b-20230523) makes the whole thing much more readable 🥰

but returning json({}) in a branch still makes the whole inference trip & fail:

We may want to open a bug report for this

/cc @pcattori

• You may be interested in checking https://github.com/kiliman/remix-typedjson

[kiliman]

Yeah, remix-typedjson kinds of punts on type inference by simply using the type that TypeScript sees since I don't have to worry about the JSON representation. My library simply converts the JSON payload back into the original object (with the correct types).

[Marcdj-02]

Yeah, you're right. The import of redirect was from the wrong package. Thanks for your tip.

Simplified types will be much better indeed. Plus, the fix of the empty object would be nice.

[iamkd]

Hi! Sorry for a tangential question, but I've been doing exactly this right now - replacing return with throw to improve types across the codebase. Because of this I've been a bit confused about the described behavior of ErrorBoundary v2. Is redirect exempt from being caught by ErrorBoundary?

I'm testing it right now and it seems that any thrown Response (doesn't matter if it's 2xx or 4xx) is caught by it, but redirect or a manual 302 Response is working as expected. I'd love to have a more clear explanation/documentation on any possible exceptions, thanks!

Edit:
Okay, after putting my thoughts into words I think I get the reason. The response headers/status are not modified by the error boundary, the boundary is just the response body. So... 302 still stays 302 when it reaches the browser and the redirect works as expected. My apologies to everyone who got the notifications 😄