Most new features are centered around better typings
You can now pass a generic parameter to EventDispatcher indicating
which type of events it will dispatch. Besides it serving as documentation to
other developers about which events to expect, it also allows this library
to add more useful typings to methods like addEventListener. Example:
class Scheduler extends EventDispatcher<SchedulerEvent> {Event classes can still be created by manually extending AbstractEvent.
However, this is somewhat verbose. Moreover, it is very common to want to
have some kind of data property on an event. This is now possible using
2 new utilities: createEventClass and createIsomorphicEventClass. See
the readme for more info.
Previously an event class was either fixed to a set of options and a certain
type of data, or it was typed too loosely. It is now possible to have the
options and the data depend on the event type.
Instead of the types being available directly on the class constructor,
they are now nested in a types property:
foo.addEventListener(new SomeEvent(SomeEvent.types.FOO, ...));A lot of private fields have been changed to protected to allow for
more extensibility
As it is now very easy to create your own strongly typed event classes, it no longer makes sense to export generic classes. Instead, we should encourage the definition of classes tailored to your project.
These interfaces contain a lot of duplication with their corresponding
classes, and were slowing down development. Typing things like so will
also remove the strong typing. The rationale behind it was that we
theoretically could have EventDispatcher interact with a custom
implementation with the same interface, but this is rarely to never done.
When wanting some kind of custom functionality, it usually suffices to
extend EventDispatcher and override the methods.
It's also worth mentioning that there was no advantage to IEvent at all,
as AbstractEvent only has public members. This makes it possible to
create a class that implements AbstractEvent.
Our new createEventClass utility has a better syntax
Tests are now implemented using Jest. Additional test have been added using
dtslint, allowing us to do assertions on the types in the TypeScript compiler.
Requires at least TypeScript 3.1, for the mapped tuple type functionality.