Consider ditching the wasm-sockets crate and either using WebSocket in web_sys or gloo_net.
I'm already using a patched version of wasm-sockets, because my pull-request hasn't been addressed. Additionally, there are calls to forget() that make me nervous. There's a tiny chance that the "old Firefox bug" (#1526) might be fixable via careful web-sys implementation now that I understand a lot of the issues better and (probably) don't need the handholding that wasm-sockets provides.
OTOH, gloo_net is already written, but doesn't support a Connected message. That's been asked for, albeit almost two years ago and there was never a response, but that could be due to the way the issue is phrased. AFAICT, it would just require adding a new variant to StreamMessage and Message and then calling sender.unbounded_send in the open callback and then have it that send the new Message variant. It would, however, be a breaking change.
Since I don't have time for this today (ha!) and since reworking the reconnecting_web_socket code to use a futures model is trickier than using web_sys directly, I'm going to ask about a offer my opinion about why a Connected message isn't needed in that issue.
I'm labeling this as bug as well as chore, because the wasm-socket forgets shouldn't be there and my suspicion is that either alternative might solve the old Firefox bug.
Consider ditching the wasm-sockets crate and either using WebSocket in web_sys or gloo_net.
I'm already using a patched version of wasm-sockets, because my pull-request hasn't been addressed. Additionally, there are calls to forget() that make me nervous. There's a tiny chance that the "old Firefox bug" (#1526) might be fixable via careful web-sys implementation now that I understand a lot of the issues better and (probably) don't need the handholding that wasm-sockets provides.
OTOH, gloo_net is already written, but doesn't support a
Connectedmessage. That's been asked for, albeit almost two years ago and there was never a response, but that could be due to the way the issue is phrased.AFAICT, it would just require adding a new variant toStreamMessageandMessageand then callingsender.unbounded_sendin the open callback and then have it that send the newMessagevariant. It would, however, be a breaking change.Since I don't have time for this today (ha!) and since reworking the reconnecting_web_socket code to use a futures model is trickier than using web_sys directly, I'm going to
ask about aoffer my opinion about why a Connected message isn't needed in that issue.I'm labeling this as
bugas well aschore, because the wasm-socket forgets shouldn't be there and my suspicion is that either alternative might solve the old Firefox bug.