Rename LoadInput to LoadEvent

[felixsanz]

Describe the bug

The endpoint's get function doesn't have type for input arguments. In javascript you can use the generated types, but that's not possible with typescript. So the whole object or individual keys should be able to type. Example:

export async function get({ params }: ThereIsNoTypeAvailable): Promise<RequestHandlerOutput> {}

export async function get({ params }: { params: ThereIsNoTypeAvailable }): Promise<RequestHandlerOutput> {}

The output is fine, RequestHandlerOutput is available and we can use it.

Yeah, you can type a function expression like this:

export const get: RequestHandler = async ({ params }) => {}

But it's impossible to type function statements right now. There's RequestEvent but it's not exported (it's private).

On the other hand, the load function is fine:

  export async function load({ params, fetch }: LoadInput): Promise<LoadOutput> {}

You can use the Load type on a function expression or LoadInput + LoadOutput on a function statement.

So we should have consistency and have both input and output types available in functions, specially get.

load()	get()
Load	RequestHandler
LoadInput	????????
LoadOutput	RequestHandlerOutput

Maybe RequestHandlerInput ?

Reproduction

NA

Logs

No response

System Info

NA

Severity

serious, but I can work around it

Additional Information

NA

[Rich-Harris]

I think we should make RequestEvent public. For consistency I wonder if we should rename LoadInput to LoadEvent.

You can use generated types with TS, though right now you need to add .d, like this:

import type { RequestHandler } from './index.d';

That'll be fixed by #4705, once we agree on exactly how it should look.

[felixsanz]

I think we should make RequestEvent public. For consistency I wonder if we should rename LoadInput to LoadEvent.

You can use generated types with TS, though right now you need to add .d, like this:

import type { RequestHandler } from './index.d';

That'll be fixed by #4705, once we agree on exactly how it should look.

I think for consistency it should be LoadInput/LoadOutput and RequestHandlerInput/RequestHandlerOutput.

Because the arguments are the function's input. And an event imo is the whole function when it's called.

[Rich-Harris]

And an event imo is the whole function when it's called.

You can think of a request handler (either in an endpoint, or the main handle hook) as being sort of analogous to a DOM event listener:

addEventListener('GET', event => {
  // ...
});

The argument to the handler callback is always called event (or evt or e), not input, and the 'event' terminology refers unambiguously to that argument, not to the addEventListener call or the handler or the invocation of the handler.

The same convention is used inside AWS Lambda:

exports.handler =  async function(event, context) {
  return {...};
};

So RequestEvent and event are the right names; I think the only question is whether to rename LoadInput to LoadEvent (I would say yes).

[Rich-Harris]

I just merged #4809 which makes RequestEvent public, so I've edited this issue to 'Rename LoadInput to LoadEvent'

[felixsanz]

Then... if this functions (get(), post()... load()) are attached/subscribed like a listener, then Event is appropriate. If they are just called... i don't think so.

I'm kinda new and don't know the sveltekit internals, but probably it just boils down to that.

[tcc-sejohnson]

@Rich-Harris

Making private types public seems to be my purpose in life. Maybe I should branch out to renaming public types...

If you'd like to rename LoadInput to LoadEvent, I'll make a PR. Just let me know your final decision. 😉