See MMB-328; I've created a corresponding issue here since ideally we'd like to keep the Spaces EventEmitter API the same as that of ably-js’s corresponding class (my understanding is that we'd like to eventually remove Spaces’ class and use that of ably-js).
It’s less obviously an issue in ably-js [than in Spaces], because usually (with the exception of the update event) the event name coincides with the name of the state that the emitting object has transitioned to, and this state is accessible via the current property of the state change that’s passed as an argument to the listener.
In ably-js, we may also want to maintain the usage of this for backwards compatibility, alongside a new argument-based way of exposing the event name.
See MMB-328; I've created a corresponding issue here since ideally we'd like to keep the Spaces
EventEmitter
API the same as that of ably-js’s corresponding class (my understanding is that we'd like to eventually remove Spaces’ class and use that of ably-js).As I mentioned on Slack:
In ably-js, we may also want to maintain the usage of
this
for backwards compatibility, alongside a new argument-based way of exposing the event name.┆Issue is synchronized with this Jira Story by Unito