Let's streamline the discussion by switching your scroll event to a keyup event since it is of type KeyboardEvent and does not fall into the broader category of Event, which could potentially overlap or conflict with MouseEvent:
const clickEvent = createEventListener({
name: "click",
callback: (ev: MouseEvent) => console.log(ev),
});
const keyupEvent = createEventListener({
name: "keyup",
callback: (ev: KeyboardEvent) => console.log(ev),
});
const events = [clickEvent, keyupEvent];
When choosing an event from events, the compiler deduces that the name property consists of a union of the string literal types "click" and "keyup". Similarly, it recognizes that the callback property is a union of function types (ev: MouseEvent) => void and (ev: KeyboardEvent) => void:
for (const event of events) {
event.name // "click" | "keyup"
event.callback // ((ev: MouseEvent) => void) | ((ev: KeyboardEvent) => void)
These inferred types are indeed accurate. It confirms that event.name will be either "click" or "keyup", and event.callback will expect a function parameter of either MouseEvent or KeyboardEvent.
Attempting to invoke event.callback, which involves a union of function types, necessitates passing in a parameter that represents an intersection of both function's parameter types. In other words, calling event.callback(x) demands that x conforms to MouseEvent & KeyboardEvent, indicating that it embodies characteristics of both a MouseEvent and a KeyboardEvent:
declare const m: MouseEvent;
event.callback(m); // error, should not be 'MouseEvent & KeyboardEvent'.
declare const k: KeyboardEvent;
event.callback(k); // error, should not be 'MouseEvent & KeyboardEvent'.
declare const both: MouseEvent & KeyboardEvent;
event.callback(both) // okay
This concept of unions of functions that require intersections of parameters is a unique aspect of TypeScript. It maintains correctness and type safety. When faced with selecting between one function demanding a MouseEvent and another needing a KeyboardEvent, providing an input that satisfies both requirements like MouseEvent & KeyboardEvent becomes crucial.
Hence, inferring event.callback as
(ev: MouseEvent | KeyboardEvent) => void
would be inaccurate. The compiler's decision here is entirely correct, even though the desired type may appear beneficial down the line.
[... continue with the remaining content ...]