Add subscriptions for connection opened and connection closed.

[bgourlie]

I believe this would solve #10

There are a number of reasons we would want to know when a connection is established or closed:

• Provide connection indicator in the UI
• Perform websocket specific authentication

Hypothetical not-well-vetted API:

type RetryInfo
     = NoRetry     -- Will not attempt to re-establish the connection
     | RetryIn Int -- Will attempt to re-establish the connection in the specified number of seconds

type alias ConnectionClosedHandler msg 
    = String    -- Connection URI
   -> Int       -- CloseEvent code
   -> RetryInfo -- Retry information
   -> msg

connectionClosed : ConnectionClosedHandler -> Sub msg

connectionOpened : (String -> msg) -> Sub msg

I wouldn't mind taking a stab at implementing this, assuming I can get some feedback on the proposed API.

[process-bot]

Thanks for the issue! Make sure it satisfies this checklist. My human colleagues will appreciate it!

Here is what to expect next, and if anyone wants to comment, keep these things in mind.

[cscalfani]

Another reason to have this is if you have a high-level protocol, i.e. app-specific protocol, that's stateful over a websocket, having the websocket reconnect and send queued items is NOT advantageous.

I think a simple solution would be to implement the following:

1. Send a message when a connection is LOST and when it's REESTABLISHED
2. Don't auto-send queued messages after a REESTABLISH
3. Add API functions to start sending queued messages AND to clear queued messages

This solution does complicate the trivial cases, so here are some possible options for that:

1. Make Auto-send an option that defaults TRUE when the websocket is established
2. Make LOST and REESTABLISHED something that the app must subscribe to, e.g. subscribe to connections status

This would make the trivial case trivial again and the complex case would have only 2 extra steps to be able to re-authenticate or re-establish some higher-level protocol state, e.g. stateful connection. And the extra API calls would be used by the complex cases (only 1 out of the 2 per case).

[jzarzeckis]

One thing I'd like to add regarding the possibility of having queued messages while the connection was down, and which accumulated during reconnect.

It's a possible case that the protocol in the server expects a certain handshake as the first message. For example passing the authentication credentials in the first message, or at least a simple "subscribe" message in certain cases.

At such cases I'd expect the queued messages to be sent only after the predefined handshake message.

Can I expect something like this to be implemented in the library, or should I resort to the Lowlevel api?

[edevil]

Is 2017 the year of the Elm Websocket? Seriously, this core lib needs some attention.

[cscalfani]

I wrote my own: https://github.com/panosoft/elm-websocket-browser.

Also a server version: https://github.com/panosoft/elm-websocket-server.

[edevil]

Thank you, but the problem in my case is other libraries that make use of elm-websocket.

[cdevienne]

Having coded https://github.com/orus-io/elm-nats, I think this feature would be super useful (especially, in my case, disconnection detection and not to auto-send queued messages).