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?
