Currently events are directly registered to objects that extend THREE.EventDispatcher. This is mainly problematic because it forces to have some circular dependencies such as here.
A possible classic implementation to avoid that is to use an event broker to which all events are registered and from which all events are dispatched. Luckily, THREE.EventDispatcher is already an event broker. Therefore, instead of implementing classes that extend THREE.EventDispatcher, I propose to create a global instance of THREE.EventDispatcher where we will register all events (like proposed in this accepted answer).
The benefits will be to ease memory management and reduce coupling between classes. It will also allow to centralize all events in one place, giving a clearer view of all the events available.
For itowns' users it will mean to listen to events from this event broker that would be exposed in the API. It will also give them a clearer view of all available events while now there are all scattered around classes and not very visible.
I agree with that. It would indeed be much simpler for user than now, where some events are triggered by different entities whereas one is in a planar view or a globe view.
Currently events are directly registered to objects that extend
THREE.EventDispatcher
. This is mainly problematic because it forces to have some circular dependencies such as here.A possible classic implementation to avoid that is to use an event broker to which all events are registered and from which all events are dispatched. Luckily,
THREE.EventDispatcher
is already an event broker. Therefore, instead of implementing classes that extendTHREE.EventDispatcher
, I propose to create a global instance ofTHREE.EventDispatcher
where we will register all events (like proposed in this accepted answer).The benefits will be to ease memory management and reduce coupling between classes. It will also allow to centralize all events in one place, giving a clearer view of all the events available.
For itowns' users it will mean to listen to events from this event broker that would be exposed in the API. It will also give them a clearer view of all available events while now there are all scattered around classes and not very visible.
WDYT?