Discussion: How can we type the events supported by a component

[AlexGalays]

The goal is to easily catch typos and help the discovery of all possible events dispatched by a component. After all, there is no reason why the inputs (props) can have a strong contract but the outputs (events) don't. In fact, it's even more important than for props, because the dispatching can occur about anywhere in the file, whereas props are usually neatly bunched together are the top.

Right now I can type on:qoidfoqidjoiqsjd just fine.

Flex, which also had its compiler used custom annotations for this: https://github.com/apache/flex-sdk/blob/master/frameworks/projects/mx/src/mx/core/Container.as#L97

Perhaps we could have a special, reserved convention like export type Events = {name: 'eventA', data: number} | ...
Having the TSDoc carry over on the consumer side tooltip would be the icing on the cake.

[dummdidumm]

The reason why this cannot be implemented easily is that it's a lot harder to collect all possible events than to collect the props. That's also the reason why autocompletion does not work because these are for props.

Looking under the hood it's that props are implemented through jsx props. Events are not because of the limitations of collecting them. If the user would explicitly type them this could be changed. We cannot mark the dispatched events as "this does not conform to the definition" though because of the challenges mentioned.

Having a reserved interface is likely the way forward. We have thought about this before in the context of generic props. Reserved interface names could be ComponentEvents, ComponentProps, ComponentSlots and ComponentDef for typing all three.

Related #304

[dummdidumm]

Getting autocompletion with on:<event> has to be done differently because under the hood we use JSX to get these autocompletions. To get autocompletion "out of the box", we would need to have on:<event> as part of the props. But this is not possible because JSX does not allow characters like : in props.
Another problem is that we somehow would need to convert the events type definition to prepend the on:, which cannot be done with TypeScript at the moment (related TS issue).

Two solutions arise from these constraints:

• Tell devs to type their events like __on__<eventName>: .. and we would in the language server then replace __on__ with on: during autocomplete. This feels suboptimal and brittle.
• Implement our "own" autocompletion for this. This is possibly a hard task, but would lead to a clean solution.

Getting "on:XXX does not exist" errors is easily possible after #386 is merged through a variation of the $on method definition not falling back to CustomEvent<any> if users type their events explicitely.

[dummdidumm]

Once sveltejs/svelte#5260 is released we can try to update svelte2tsx so that it searches for createEventDispatcher, looks if it has a type annotation, and if yes, uses that to get proper types.

[dummdidumm]

You can now take advantage of the createEventDispatcher typing introduced in Svelte 3.25.0. If you do

const dispatch = createEventDispatcher<{foo: string; bar: boolean}>();

You get strong typing for dispatch within the component, and if you listen to the foo/bar events, you'll get strong typings:

on:foo={e => ... // <- e is of type CustomEvent<string>

You'll also get much better autocompletion for events now. Note however that you are still allowed to listen to other events, so type safety in the sense of "only listen to events defined through createEventDispatcher" is still only possible through the ComponentEvents interface. But we plan on providing something (maybe a script tag attribute) which would make the events strict.

Related docs: https://github.com/sveltejs/language-tools/blob/master/docs/preprocessors/typescript.md#typing-component-events

[linuxuser586]

@dummdidumm

Any ideas on why some listening events for createEventDispatcher don't receive the type?

Example:

// Component Foo
const dispatchFoo = createEventDispatcher<{foo: string; bar: boolean}>();
const dispatchBar = createEventDispatcher<{bar: string; baz: string}>();

// Component Bar
// e is CustomEvent<any>
on:foo="{(e) => handleFoo(e.detail.bar)}"
// e is CustomEvent<{baz: string}>
on:bar="{(e) => handleBar(e.detail.bar)}"

The typescript compiler catches this as expected.

Changing the order produces different results.

if the createEventDispatcher order changes, then the typescript compiler does not catch the error.
It appears that only the last createEventDispatcher produces the type for the listener.

// Component Foo
const dispatchBar = createEventDispatcher<{bar: string; baz: string}>();
const dispatchFoo = createEventDispatcher<{foo: string; bar: boolean}>();

// Component Bar
// e is CustomEvent<{bar: boolean}>
on:foo="{(e) => handleFoo(e.detail.bar)}"
// e is CustomEvent<any>
on:bar="{(e) => handleBar(e.detail.bar)}"

The typescript compiler does not catch the error since the type is now CustomEvent<any>.