add loader inference

[kentcdodds]

I'm not getting the loader inference I expected. data ends up being any. Am I doing something wrong here @colinhacks?

[penspinner]

Suggested change

	export const loader: LoaderFunction = async ({ request }) => {
	export const loader = async ({ request }: LoaderArgs) => {

What happens if you remove LoaderFunction?

[mcansh]

yup, need to type the args and not the full function as LoaderFunction returns Promise<Response> | Response | Promise<AppData> | AppData where AppData is actually just any

[kentcdodds]

Yikes. I don't remember agreeing to that. How do we avoid that?

[kentcdodds]

FWIW, it does work. But is there any way we can avoid having to type the args? I'd much rather type the whole function and get type safety on what's returned as well as the args.

[kentcdodds]

Though I could be convinced. I just don't remember signing up for this so I need to process it a bit...

[MichaelDeBoey]

I hate the fact that we need to type args instead of the whole function, but I like the type inference so it's a hard one for me 😕

[chaance]

Agreed, but I think the choice here was constrained by this being a breaking change if we changed the LoaderFunction/ActionFunction types. Seems like something we'll have to reconsider for v2.

[kentcdodds]

Ok, after looking at it more, I realize that it's required for TypeScript to infer the return type. My mistake. Fixing now.

[pcattori]

If/when the satisfies operator makes it into Typescript, we'll get the best of both worlds:

// syntax for `satisfies` TBD
const loader: satisfies LoaderFunction = () => { // TS will error if `loader` doesn't conform to `LoaderFunction`
  return json({ hello: "world"}) // ... but will still infer the narrower return type here
  // ^ use `{hello: "world"} as const` if you want `"world"` literal type instead of just `string`. standard TS thing
}

[kentcdodds]

Even better: microsoft/TypeScript#38511