Add support for buffering data and sending it once connection is open

[Jokero]

This is very useful when connection is aborted and you are trying to send something unsuccesfully. Until connection is open again, all data are buffered and will be sent once reconnection happened

[porsager]

I agree it could be useful, but it's also very easy to implement yourself, and often has some custom requirement for each project which is why I'm not including it here..

Here is a very simple reference implementation you can use (not tested):

const socket = new PersistentWebSocket('...')
    , queue = []

socket.addEventListener('open', () => {
  while (queue.length) socket.send(queue.shift())
})

function send(message) {
  socket.readyState === 1
    ? socket.send(message)
    : queue.push(message)
}

You can also take a look at UBRE if you're feeling adventurous.. The js lib for that does what you're asking and some more.

[Jokero]

Yeah, I agree it's not difficult to implement on your own.

I've just noticed that there are a lot of similar libraries and they provide different set of features (autoreconnection + heartbeat, autoreconnection + buffering or just only autoreconnection). There is no a lightweight library working with vanilla WebSocket and supporting all of these basic features.

So currently it will look like wrapper of wrapper of wrapper. And this is without any warranty that it will work well when you use these wrappers from different libraries together.

The problem is compounded by the fact that this functionality is usually needed for both client and server. So you can either write the same code twice for client and server or move it to a shared library what is also not very convenient.

[porsager]

Yeah, that's been my experience too, and I ended up making UBRE to solve that for my own / company projects. Did you have a look at that?

[Jokero]

I've checked and it looks really similar to https://github.com/bminer/ws-wrapper. UBRE is transport agnostic though.

For my use case UBRE looks like overcomplicated solution, since I just need buffering feature (in addition to WebSocket persistence of course). Maybe it will be easier to write my own wrapper for it, at least for now

[roelvan]

Really like this package @porsager, thanks for your work! 👊 I agree, keeping this package lean is the better decision. Just focus, as you do, on the basics: timeouts, backoff, offline / online handlers. The rest is up to the user/project (buffering, handshake with the server,...).

[porsager]

Thanks @roelvan

I agree, this library does what it should currently, so I'll close this issue 🙂