Revamp the events API
Chalarangelo opened this issue · 1 comments
Motivation
The events API is clunky and not very useful. It also makes for a poor development experience both internally and when using the library.
Proposal
Remove the current API and move away from each class extending EventEmitter. Instead, create a centralized messaging system that will emit events both internally and to external consumers. These events can then be more useful and designed with actual use-cases in mind (e.g. #4).
Based on implementation changes landing after #27 is merged, we can expect to have a significantly smaller set of model change events and a lot more to do with records and querying. In fact, that's where the bulk of the event emission should take place as it's the part developers interact the most with.
Considerations
The events API is not well-documented at this time and is of very little use in most cases. If, after other changes are merged, it still feels like an afterthought, it might be better to call it a day and completely remove anything event-related.
Not planning to use the events API any time soon. Deprecating for now.