Infer types of the loader function #2937

mellson · 2021-03-14T09:23:14Z

mellson
Mar 14, 2021

It would be nice to infer the type of the loader function when using useRouteData.
I'm not sure how the internals of remix work, so I don't know if there's anywhere one could hook (pun intended) into the place where the actual loading occurs.

Anyway, here is a small utility that could help someone else needing an easy way to get the types.

This code (placed in a helper file somewhere):

import { LoaderFunction } from "@remix-run/data";
import { useRouteData } from "@remix-run/react";

type Awaited<T> = T extends PromiseLike<infer U> ? Awaited<U> : T;
export type LoaderType<T extends LoaderFunction> = Awaited<ReturnType<T>>;

export function useTypedRouteData<T extends LoaderFunction>(loader: T) {
  return useRouteData<LoaderType<typeof loader>>();
}

allows the user to get the types in one of two ways:
1 - Add the type to the existing hook let data = useRouteData<LoaderType<typeof loader>>()
2 - Use the provided wrapper let data = useTypedRouteData(loader)

This should work equally well with promises and responses. But there's probably a lot of edge cases I'm not thinking of right now.

JNaftali · 2021-05-06T05:20:20Z

JNaftali
May 6, 2021

Now that the source is released I did a bit of messing around and think I found an ideal way to implement by modifying some of remix's own types.

from responses.ts:

export interface ResponseWithBody<Body> extends Response {}

/**
 * A JSON response. Converts `data` to JSON and sets the `Content-Type` header.
 */
export function json<Body>(
  data: Body,
  init: number | ResponseInit = {}
): ResponseWithBody<Body> { /* snip */ }```

and from routeModules.ts:
```ts
/**
 * The argument that is passed to a LoaderFunction
 */
export type LoaderFunctionArg = {
  request: Request;
  context: AppLoadContext;
  params: Params;
};

/**
 * A function that loads data for a route.
 */
export interface LoaderFunction {
  (args: LoaderFunctionArg):
    | Promise<Response>
    | Response
    | Promise<AppData>
    | AppData;
}

/**
 * Used to infer the JSON body of a LoaderFunction
 */
export type InferLoaderData<
  Loader extends (arg: LoaderFunctionArg) => any
> = Loader extends (arg: LoaderFunctionArg) => Promise<infer Resp>
  ? InferLoaderData<(arg: LoaderFunctionArg) => Resp>
  : Loader extends (arg: LoaderFunctionArg) => ResponseWithBody<infer Body>
  ? Body
  : Loader extends (arg: LoaderFunctionArg) => Response
  ? never
  : ReturnType<Loader>;

With that, loader types can be inferred like the following:

export async function loader() {
  return {
    hello: 'world'
  }
}

export default function Page() {
  // routeData is inferred as type { hello: string }
  let routeData = useRouteData<InferLoaderData<typeof loader>>()
  return null

0 replies

eps1lon · 2021-05-06T15:12:42Z

eps1lon
May 6, 2021

Alternative suggestion:

interface AppData {
  hello: string;
}

// new type parameter for `MetaFunction`
export let meta: MetaFunction<AppData> = () => {}
// new type parameter for `LoaderFunction`
export let loader: LoaderFunction<AppData> = () => {}
export default function Page() {
  // already works
  let data = useRouteData<AppData>();
  return null;
}

Because it's not always clear if the loader or meta or Page should decide the correct shape of the AppData. By declaring an explicit interface we have a more neutral source of truth.

And it's just straight up easier to grok and removes some of the burden from the TypeScript compiler. Because the compiler might eventually break down with inference and give you an any without you knowing.

0 replies

JNaftali · 2021-05-06T17:14:37Z

JNaftali
May 6, 2021

Declaring the type explicitly is all well and good but I think this issue is about how to avoid doing that. That's what it means to infer a type (https://www.typescriptlang.org/docs/handbook/type-inference.html).

Depending on inference has drawbacks but also has benefits, and it's a choice I'd like Remix to offer

0 replies

eps1lon · 2021-05-06T17:23:59Z

eps1lon
May 6, 2021

With my proposal the inference from the loader function is trivial:

import type { LoaderFunction as RemixLoaderFunction } from 'remix';
type AppData<LoaderFunction> = LoaderFunction extends RemixLoaderFunction<infer AppData> ? AppData : never

0 replies

JNaftali · 2021-05-07T02:07:08Z

JNaftali
May 7, 2021

The code would be more complicated than you make it out to be because many loader functions (including anything that uses the json helper) will return a Response, which is not a generic type. There is no way to get a useful type out of Response.body - it's just a string. That's why I suggested modifying the call signature of the json helper, and why my InferLoaderData type is more complicated than your AppData type. Making LoaderFunction and MetaFunction into generics is probably also be a good idea, but that wouldn't make inference possible on it's own.

0 replies

eps1lon · 2021-05-07T08:31:15Z

eps1lon
May 7, 2021

There is no way to get a useful type out of Response.body - it's just a string

That is my suggestion of course. To add a generic argument. Let's be a bit more generous with each positions, shall we? I expected that it's obvious that my proposal isn't possible today. That's why I proposed it. Otherwise there wouldn't be anything to argue about.

Making LoaderFunction and MetaFunction into generics is probably also be a good idea, but that wouldn't make inference possible on it's own.

How so? What would work with type AppData<LoaderFunction> = LoaderFunction extends RemixLoaderFunction<infer AppData> ? AppData : never?

0 replies

JNaftali · 2021-05-08T03:16:52Z

JNaftali
May 8, 2021

You're right that we're basically agreed about what we'd like to see added to Remix and are arguing about implementation details. And that's probably a silly thing to do without some signal of intent from Ryan/Michael.

0 replies

joshmedeski · 2022-01-21T19:03:58Z

joshmedeski
Jan 21, 2022

I got something working. I made the following changes.

Drop the loader LoadFunction type on the loader function and use the DataFunctionArgs argument type. This is so Typescript can infer the return type of loader.

import { DataFunctionArgs } from '@remix-run/server-runtime'

export const loader = async ({ params }: DataFunctionArgs) => {
  invariant(params.movieId, 'expected params.movieId')
  const details = await new Tmdb().movie.getDetails(params.movieId)
  return { details }
}

Create a useInferredRouteData reusable type. This extends the useLoaderData function and infers the returned type from the promise.

export function useInferredRouteData<
  T extends (args: DataFunctionArgs) => any
>() {
  return useLoaderData<Awaited<ReturnType<T>>>()
}

Include typeof loader as the generic on the useInferredRouteData hook.

export default function Index() {
  const { details } = useInferredRouteData<typeof loader>()

Warning: I realize that this is incomplete. If you have conditional response types on the loader function you may run into errors with this code. But it's great for a happy path and the useInferredRouteData type can be separated so it can be easily reused.

Type Name Suggestion: I'd also suggest to the remix team that DataFunctionArgs be changed to LoaderFunctionArgs to better match the API.

0 replies

itsMapleLeaf · 2022-01-22T00:23:07Z

itsMapleLeaf
Jan 22, 2022

Type Name Suggestion: I'd also suggest to the remix team that DataFunctionArgs be changed to LoaderFunctionArgs to better match the API.

I thought the same too at first, but I figure it's called that because the same args are also used for the action function

0 replies

itsMapleLeaf · 2022-01-22T00:31:02Z

itsMapleLeaf
Jan 22, 2022

Related to the subject, here are a set of typed helpers I've written up that I'm making good use of: https://gist.github.com/itsMapleLeaf/0521a21e5e24419ce90d447e7ceede70

0 replies

Infer types of the loader function #2937

Uh oh!

Uh oh!

Replies: 10 comments

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!