Enhancing LoaderFunction with TS generics

[benallfree]

Hello, I have a suggestion for genericizing LoaderFunction and adding helper factory for improved Typescript support.

First, a generic LoaderFunction type:

export interface LoaderFunction<TAppData extends AppData = any> {
  (args: DataFunctionArgs):
    | Promise<Response>
    | Response
    | Promise<TAppData>
    | TAppData
}

This would be backward compatible but would also mean that the function return type can be picked up by Typescript.

Next, I created a factory helper that accepts a loader function and returns the typed loader and a typed useLoaderData:

export const makeLoader: <T>(ld: LoaderFunction<T>) => {
  loader: LoaderFunction<T>
  useLoaderData: () => T
} = (ld) => {
  return {
    loader: ld,
    useLoaderData: _useLoaderData,
  }
}

I like this approach because then I don't need to create any custom types. It can all be inferred from the loader function return type.

const { loader, useLoaderData } = makeLoader(() => {
  const serverNames = keys(rootState)
  return { serverNames }
})

export { loader }

export default function Index() {
  const { serverNames } = useLoaderData()
  return (
    <>
        {serverNames.join(', ')}
    </>
  )
}

Thoughts?

[hollandThomas]

There's a somewhat similar discussion here
#1401

Ryan explains why it's kind of a bad idea here
#1254 (comment)

That being said, there is a library that does what you want
https://github.com/joeflateau/remix-superloader

There's also the more mature superjson that you could use to implement de-/serializing complex objects in your app yourself
https://github.com/blitz-js/superjson

And a corresponding discussion to have that one baked into Remix
#1910

And finally, a closed PR that should give you an idea on what to do to achieve that
#662

[kiliman]

We need a bot that automatically answers this question any time there's LoaderFunction + TypeScript.

[hollandThomas]

I think this one qualifies more than almost anything for a well written entry in the FAQ page^^
https://remix.run/docs/en/v1/pages/faq

[kiliman]

They are planning to deprecate returning naked objects from loaders, so you'll have to create a new Response or use one of the helpers like json.

This will make it clear that the return type of loader is always a Response.

If they want to get inferred types for userLoaderData then they should have a function that returns the data and use the type inference from there.

const loader: LoaderFunction = () => {
  const data = getData()
  return json(data)
}

const data = useLoaderData<ReturnType<typeof getData>>()

But unless you're using something like superjson, if your data includes non-standard JSON types like Date, your "type" won't be correct.

[kiliman]

In addition to the response from @hollandThomas, you should not wrap your loader function in a HOC. The reason is that your loader will now be included in your client bundle.

Your makeLoader function is executed in module scope, so it cannot be tree-shaken.

[benallfree]

Thanks everyone. This sounds very similar to why Firestore doesn't use generics - ie, you don't actually know what's coming across the wire and it should be considered untrusted by client code.

[benallfree]

Agreed it will make a lot more sense when LoaderFunction only returns Response.

type-fest could be helpful for constraining what AppData is. They/we are working on a Jsonifiable type where something is Jsonifiable if serialization/deserialization will be compatible with the original type. This could be quite helpful in catching cases where serialization/deserialization would mutate the type (ie the type on the server is NOT compatible with the type you get from useLoaderData.

export type AppData = Jsonifiable

export function useLoaderData<T extends AppData>(): T {
  return useRemixRouteContext().data;
}

const getData = ()=> { ... }
export const loader = ()=>return new Response(...)
export default Index:FC = ()=>{
   const myData = useLoaderData<ReturnType<typeof getData>>() // This would produce a type error if getData()'s return type was not Jsonifiable
}