See ably/ably-js#1347 for discussion + example implementation.
The motivation for this change is to allow users, when using rewind=1, to wait for rewind messages to have been received (this wasn't possible before since there was no way to determine whether a rewind message is to be expected)
Returning ChannelStateChange from attach/subscribe is an API convenience which makes sense given that both methods return a promise/future/whatever resolving when the channel is attached and, by convention, information about the attachment is exposed via ChannelStateChange objects.
I don't expect there to be a demand for either of these features outside of ably-js so I've described both as optional.
See ably/ably-js#1347 for discussion + example implementation.
The motivation for this change is to allow users, when using
rewind=1, to wait for rewind messages to have been received (this wasn't possible before since there was no way to determine whether a rewind message is to be expected)Returning
ChannelStateChangefrom attach/subscribe is an API convenience which makes sense given that both methods return a promise/future/whatever resolving when the channel is attached and, by convention, information about the attachment is exposed viaChannelStateChangeobjects.I don't expect there to be a demand for either of these features outside of ably-js so I've described both as optional.