- rename "connect_error" to "error"
- remove "reconnecting" (duplicate of "reconnect_attempt")
The updated list of events emitted by the Manager:
- open: successful (re)connection
- error: (re)connection failure (previously: "connect_error") or error after a successful connection
- close: disconnection
- ping: ping packet
- packet: data packet
- reconnect_attempt: reconnection attempt (previously: "reconnect_attempt" & "reconnecting")
- reconnect: successful reconnection
- reconnect_error: reconnection failure
- reconnect_failed: reconnection failure after all attempts
For reference, the Socket instance emits the following events:
- connect: successful connection to a Namespace
- connect_error: connection failure
- disconnect: disconnection
The meaning is not modified: this packet type is still used by the
server when the connection to a namespace is refused.
Breaking change: the Socket instance will now emit a "connect_error"
event instead of "error" (which is not a reserved event anymore)
```js
// before
socket.on("error", () => {});
// after
socket.on("connect_error", () => {});
```
Inspired from EventEmitter2 [1]
The API is similar to the one on the server-side:
```js
socket.onAny((event, ...args) => {});
socket.prependAny((event, ...args) => {});
socket.offAny(); // remove all listeners
socket.offAny(listener);
const listeners = socket.listenersAny();
```
[1]: https://github.com/EventEmitter2/EventEmitter2
A volatile packet will be dropped if:
- the socket is not connected
- the low-level transport is not ready (for example, a HTTP POST request is already pending)
Syntax:
```js
socket.volatile.emit("volatile event", "might or might not be sent");
```
This event was added in 41956806a7
But it does not convey the information that the Socket is actually
sending a CONNECT packet to the server. It should maybe be moved to the
Socket#onopen() method, but let's remove it for now as it is not
documented anywhere.
These events cannot be used by the end users, because they are part of
the Socket.IO public API, so using them will now throw an error
explicitly.
Related: f7ed81e5d2
Previously, most of the events emitted by the Manager were also emitted
by the Socket instances, but it was somehow misleading for the end
users because they don't have the same meaning:
- Manager: the state of the low-level connection (with connection and reconnection events)
- Socket: the state of the connection to the Namespace (only 'connect', 'disconnect' and 'error')
For example, the `reconnect` event:
```js
socket.on("reconnect", () => {
console.log(socket.connected); // might be false, which is a bit surprising
});
```
Breaking change: the Socket instance will no longer forward the events
of its Manager
Those events can still be accessed on the Manager instance though:
```js
socket.io.on("reconnect", () => {
// ...
});
```
It was included by the previous commit, but the test code is not
currently transpiled to ES5 so it breaks IE in the CI.
Let's use a plain function for now.
The newer versions need to be transpiled to ES5, so we'll rollback for
now as it breaks IE11.
We'll have to find a way to provide the users who bundle the Engine.IO
(or Socket.IO) client (with webpack for example) with a source code
which does not include debug (or document the usage of
webpack-remove-debug [1]).
[1] https://github.com/johngodley/webpack-remove-debug
It seems Node.js 12 (which is now 'latest') does not work with Gulp v3. In the future, we will
either have to migrate to Gulp v4, or remove Gulp from the build system.
