StreamDataWebSocketManager web socket closed after browser tab becomes inactive

DataChangeEvents
1

Normally, the Web Socket is “kept alive” by the following code

this.keepAlive = setInterval(() => {
  if (this.state === 'OPEN') {
    this._webSocketSubject && this._webSocketSubject.next({
      discriminator: 'Ping'
    });
  }
}, this.keepAliveInterval);

This behavior changes when the browser tab is no longer active. It seems like browsers throttle/change certain behavior when a tab is in the background to help with performance. This stops the keepAlive setInterval from executing. As a result, the following is executed

socket.onclose = function (e) {
  _this._resetState();

  var closeObserver = _this._config.closeObserver;

  if (closeObserver) {
    closeObserver.next(e);
  }

  if (e.wasClean) {
    observer.complete();
  } else {
    observer.error(e);
  }
};

and the socket is closed. The CloseEvent reason is blank. While I am researching what kind of behavior is desirable, I wanted to react out and crowd source to see if others have witnessed this and have come up with their own solutions to ensuring the user comes back and the page updates accordingly to prevent continuing to show potentially stale data.

2

The current best known path for this is for domains to implement reconnect logic when the dataChangeEventManager disconnects.

If you are in react and need your DataChangeEventQueries to re-register then you can track your dataChangeEventManager on react state and then set the state with your new dataChangeEventManger that has been reconnected. And then all of your useEffects that register DCEQs will run again

3

Our team is running into this issue while introducing websockets into our app. We initially were going to hold off on handling the reconnect scenario until later, but noticed that after the websocket is closed, the useDataObject(s) hook will continue to try to connect, fail, and then cause pretty significant slowdown to rendering times until the user refreshes the page.

I’ve tried the above suggestion, and it sort of works, but our dataChangeEventManager lives in a context provider to be available to the whole app. Updating the dataChangeEventManager causes a re-render to anything dependent on the context, which has some undesirable side effects like losing data on a form if it’s forced to re-render.

We’re currently using LEAF 3.1, and I know the more recent versions of LEAF include a new implementation that handles reconnects. I’m trying to determine if our app needs to undergo some code changes to better handle recreating the dataChangeEventManager, or if we’re better off putting our effort into doing an upgrade.

Looking for any insight on the best path to take, or possibly a solution I haven’t thought of yet.