Socketcluster Client Versions Save

JavaScript client for SocketCluster

v8.0.1

6 years ago

Added support for batch unsubscribe.

v8.0.2

6 years ago

Improved handling of badly formatted message.

v9.0.0

6 years ago

Added a new close event which triggers on both disconnect and connectAbort.

v7.0.1

6 years ago

Fixed broken tests due to expired auth tokens.

v7.0.0

6 years ago

socket.authState can no longer be in a 'pending' (socket.PENDING) state.

The 'pending' authState represented the ambiguous authentication state which might occur when the socket is disconnected/offline. It was removed because it was too ambiguous to be useful. Instead, socket.authState now reports the last known authentication status (optimistic approach).

Once a socket is authenticated with a valid JWT, the socket will now report itself as being 'authenticated' until the server explicitly indicates otherwise (e.g. the server invalidates the token).

Note that this only affects the authState property and the events related to it. Pub/sub channels are not affected; the 'pending' state is still supported for SCChannel objects (the meaning of 'pending' is a lot clearer in that context).

Breaking changes:

  • Front-end authentication logic which makes explicit comparisons between socket.authState and 'pending' or socket.PENDING may need to be reworked to deal with only two states: 'unauthenticated' (socket.UNAUTHENTICATED) and 'authenticated' (socket.AUTHENTICATED).
  • Front-end authentication logic which listens for the 'authStateChange' event may be affected since there are now only two possible auth states instead of three.

v6.4.0

6 years ago

Internal cleanup.

v6.3.0

6 years ago
  • Improvements to error transmission.

v6.2.2

6 years ago
  • Fixed an issue which meant that subscriptions could get processed when authenticating - In spite of the autoSubscribeOnConnect being false and not yet having called the processSubscriptions callback inside the 'connect' handler.

v6.2.0

6 years ago
  • You can now optionally assign a priority to each channel - This will determine the order in which subscriptions are sent to the server - This includes auto-resubscription when the socket recovers from a connection failure. The priority must be a number; the higher the priority, the sooner the subscription will be processed. So if you have socket.subscribe('bar').priority = 2; and socket.subscribe('foo').priority = 3; then the subscriptions will be sent to the server in the order
    #
    1: foo,
    #
    2: bar.
  • Fixed a bug which meant that pending channel subscriptions would always be processed just before triggering the 'connection' event; even when autoProcessSubscriptions / autoSubscribeOnConnect was set to false. Note that if you aren't using the autoProcessSubscriptions / autoSubscribeOnConnect option, then this bug will not affect you. If you do use autoProcessSubscriptions / autoSubscribeOnConnect, then this bug may also not affect you (but this strictly depends on your specific use case).

Breaking change:

  • autoProcessSubscriptions option has been renamed to autoSubscribeOnConnect.

v6.1.1

6 years ago

Minor cleanup.