Do not kill entire chat window when websocket closes.

[ProjectMoon]

Reopens the websocket on close. Prevents badly configured reverse proxies from making the application stop working. In my testing, I've noticed that the websocket simply reopens when the connection is closed. Instead of setting error state to true on websocket close, we just clear the websocket out using the provided React setWs function.

[ItzCrazyKns]

In case of a valid reason from the backend, if the WS is closed then it would constantly try to reconnect and then the error message would pop up again and again so I cannot merge this.

[ProjectMoon]

Is there a way to communicate the reason then? There needs to be a better solution than just putting the entire page into error state.

Maybe exponential backoff? Attempt to reconnect immediately, then if it fails, back off for X seconds, then more seconds, and so on.

[ProjectMoon]

Alternatively, can check the error state when onClose. That will make it be able to prevent reconnect attempts if not just a normal close.

I wouldn't just close the entire PR, at least.

[ItzCrazyKns]

Alternatively, can check the error state when onClose. That will make it be able to prevent reconnect attempts if not just a normal close.

I wouldn't just close the entire PR, at least.

There are certain states when no error is being sent and the WS close

[ProjectMoon]

In that case, wouldn't we want to try immediate reconnection then? And exponential back off would handle that issue if we cannot reconnect.

[ProjectMoon]

Also, after testing this more locally by killing the backend server and thus the websocket connection, it doesn't appear to attempt to reconnect. But this test only covers a sudden connection drop from the backend.

[ProjectMoon]

Small update: Do not set connection to null if in error state. I'm still trying to work out the best way to do exponential backoff in the current architecture. Do you have any suggestions?

[ItzCrazyKns]

State does not gets updated instantly (they are asnyc without a callback), if the WS closes and the error state takes time to be set, the page would still be set to null and this would repeat

[ProjectMoon]

How about something like awaiting the setError, and then using setTimeout with a 0 interval to wait until the next event loop tick for checking the value?

[ItzCrazyKns]

How about something like awaiting the setError, and then using setTimeout with a 0 interval to wait until the next event loop tick for checking the value?

Wait won't work as it doesn't returns a callback function, the setTimeout method is not efficient, 0 ms interval it would check the value a lot of time and might suck the resources.

[ProjectMoon]

When using setTimeout with a delay of 0, it forces an execution on next event loop. It's kinda like process.nextTick in node. In any case, what is your suggested way?

[ProjectMoon]

Latest iteration has useRef for reconnecting websocket with exponential backoff. And as a side-note, I learned that useRef existed today.