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.
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
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:
__on__<eventName>: ..
and we would in the language server then replace __on__
with on:
during autocomplete. This feels suboptimal and brittle.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.
Once https://github.com/sveltejs/svelte/pull/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.
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
@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>
.
Most helpful comment
You can now take advantage of the
createEventDispatcher
typing introduced in Svelte 3.25.0. If you doYou get strong typing for
dispatch
within the component, and if you listen to thefoo
/bar
events, you'll get strong typings: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 theComponentEvents
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