Elm Phoenix Socket integration (not elm-phoenix-socket)

So I’ve been looking at learning/integrating Elm into a new section on my server software as it would be especially well suited to it, however there were a lot of other Javascript modules on the page/site that already use the websocket and when I tried to use elm-phoenix-socket I found a multitude of problems, the first and largest of which was that it had no method of being able to share an Elm and Javascript websocket, as well as others like no heartbeats (at the time), no presence (I use it in a surprisingly large amount of ways now), and no longpolling support. Thus I shelved Elm for a bit and started to write it in redux/react.

Well got fed up with javascript again so tried elm again, this time ignoring elm-phoenix-socket’s existence and communicating via ports. I’m quite new to Elm so I have no clue if this is the ‘usual’ API style, but it seemed natural to me from Elixir/Erlang. I can use an existing javascript phoenix socket and all the javascript capabilities (that I have needed so far) via methods like:

init : ( Model, Cmd Msg )
init = ( Model 
  -- snip things
  , Phoenix.connect_to
    { topic="Messenger:public"
    , timeout_ms=Nothing -- Just 10000 -- Default value
    , chanCloseCB=Nothing
    , chanErrorCB=Nothing
    , joinData=null
    , joinEvent=[]
    , onPorts=
      [ {portName="onMyChannelMsg", msgID="some:msg", cb_data=null}
      -- , other message listeners

And so when I receive a “some:msg” from the phoenix server via the Phoenix socket (websocket/longpolling/whatever, we have some old ‘browsers’ here that do not have websocket support) it will then call back to the port with the name of portName (“onMyChannelMsg” in this case) with a record like:

type alias ChannelGenericMsg =
    { topic : String
    , msgID : String
    , msg : Json.Decode.Value
    , cb_data : Json.Decode.Value

So I can define all the ports I want of the form of:

port onMyChannelMsg : (Phoenix.ChannelGenericMsg -> msg) -> Sub msg

So I can listen to whatever messages I want, passed into whatever calls I wish and I have similar calls for sending a message, being able to (un)register channels on the fly and fixup presence data (not needed anything else yet).

So is this normal Elm design, is something going to horribly break with this design?


How did your socket story go? I’m just now adding websockets to an elm app, and it appears the available Elm options don’t allow key-value pairs to be passed at connect time (when /web/channels/user_socket#connect is called). That’s awkward, because that’s where the Phoenix book suggests you do authentication via Phoenix.Token. Authentication could be done at channel-join time, I guess, but this not being allowed makes me wonder if any of the Elm options are ready for production use.

Um… I think I see, by looking at phoenix.js that Phoenix gets its params from uris like ws://localhost:4000/socket/websocket?auth_token=foo

Yeah I ended up writing my own elm phoenix library, still using it to this day. Socket setup is in javascript because I had other javascript code that needed access to it too.