search

SocketCluster / socketcluster-client

JavaScript client for SocketCluster
MIT License
291 stars 92 forks source link

Using emit('subscribe', {}) does not send message #58

Closed marchaos closed 6 years ago

marchaos commented 7 years ago

It seems that 'subscribe' is used internally, as any other string that I tried seems to work. Can we add a delimiter to the internal message so that 'subscribe' works?

jondubois commented 7 years ago

@marchaos You cannot use event names which are local events on the socket.

There are three types of events in SC:

Protocol events are sent over the wire and always start with a '#' prefix so that they don't interfere with custom over-the-wire events (this is because they are meant for internal use by SC only). Unfortunately, local events are different - They do not have any prefix - That is because we wanted SC to be consistent with Socket.io and also to keep the even names short (since they are likely to be used often) but I agree that this is less than ideal.

If you try to emit a local/reserved event on the socket, it will be emitted locally on the current socket and not reach the socket on the opposite side of the connection.

The list of local/reserved events is here: https://github.com/SocketCluster/socketcluster-client/blob/31f13f492b818c5ab943560d3e36b3ec5b674fe4/lib/scsocket.js#L54-L71

So in the meantime, you should avoid emitting those events. One foolproof strategy is to add a prefix to all your custom events like 'mynamespace.myevent'.

We plan to break API compatibility for version 6 of SC (though we want to keep the upgrade process simple and straight forward) so that would be a good opportunity to rethink this behavior. If we add a special prefix to the event name; we would have to do it for ALL local events (this will make all the event names quite long and ugly). One possible solution could be to to make it such that events which come from the opposite side of the socket could have their own event listener function (E.g. instead of using the socket.on(eventName, handler) we could have a separate socket.capture(eventName, handler) or socket.handle(eventName, handler) or socket.receive(eventName, handler)... just for events which were emitted remotely)... Happy to hear suggestions.

This is a tricky 'grey area' issue so it would be nice to get input from the community.

jondubois commented 6 years ago

New versions of the client now emit an error event when you try to emit a reserved event name.