Add state machine to ReconnectingWebSocket

[EhabY]

Summary

• Replace multiple boolean flags with a single ConnectionState enum for clearer state management
• Improves code readability and makes state transitions explicit

Changes

Refactored ReconnectingWebSocket to use a state machine pattern with six states:

• IDLE - Initial state, ready to connect
• CONNECTING - Actively running socket factory
• CONNECTED - Socket is open and working
• AWAITING_RETRY - Waiting for backoff timer before reconnection
• DISCONNECTED - Temporarily paused, user must call reconnect() to resume
• DISPOSED - Permanently closed, cannot be reused

This makes the websocket lifecycle easier to understand and debug, and prevents invalid state combinations that could
occur with independent boolean flags.

Closes #754

[mafredri]

Nice refactor. Added some comments and questions, but the general theme I see that could be improved upon is the robustness of maintaining the correct state during asynchronous code execution. Right now it seems like there are a few minor edge cases where the state machine might not be fully protected against an unintended transition.

Some suggestions to tighten up the state machine include:

• Ensure there's fewer (or ideally one) code-path for state transitions.
• Track connection ID in async handlers to prevent stale transitions.

PS. A state machine diagram showing states and their possible transitions may be useful.

[mafredri]

Are we expecting something may asynchronously change this state considering we just set connecting?

[EhabY]

Yes, JS is single threaded but it's async so there could be a case where we await socketFactory and then during that we call reconnect/dispose... etc

[EhabY]

• Ensure there's fewer (or ideally one) code-path for state transitions.

Would it make sense to add something like this here:

function reduceState(
	state: ConnectionState,
	action: StateAction,
): ConnectionState {
	switch (action.type) {
		case "CONNECT":
			switch (state) {
				case ConnectionState.IDLE:
				case ConnectionState.CONNECTED:
				case ConnectionState.AWAITING_RETRY:
				case ConnectionState.DISCONNECTED:
					return ConnectionState.CONNECTING;
				default:
					return state;
			}
...

That way it's a true state machine and if the state does not change then we return false so that can be handled

[mafredri]

Would it make sense to add something like this here:

[...]

That way it's a true state machine and if the state does not change then we return false so that can be handled

Your suggestion makes sense to me and seems like a simple way to make the state machine easier to follow. 👍🏻

[EhabY]

Implemented a reducer function - BTW the last commit is unrelated but I added it because it was causing WS leaks to happen more frequently (basically only reconnect if we are not connected)

[mafredri]

LGTM, nice work!