Have you had a look at (the currently not released) https://github.com/saschatimme/elm-phoenix? Phoenix channels have request/response semantics built in which you can use in elm-phoenix via Phoenix.push - https://github.com/saschatimme/elm-phoenix/blob/master/src/Phoenix.elm#L85. See Push.ok for adding a response handler https://github.com/saschatimme/elm-phoenix/blob/master/src/Phoenix/Push.elm#L69.
On Saturday, 15 October 2016 01:04:32 UTC+2, Mark Hamburg wrote: > > We have an app based on making multiple HTTP requests to a server for > various pieces of information. All of these requests get implemented as > tasks that more or less immediately become commands which then get routed > via tagging functions as they flow up through the model. Pretty standard > stuff. (I think in 0.18, we get to ignore the task aspect.) > > We're interested in exploring using web sockets or Phoenix channels as an > alternative. Now, the request would go upstream on the socket with a tag > (probably just a number) and the response would come back down bearing the > same tag. > > To keep the same general style of coding as in the HTTP case, it seems > like the best implementation would be to use the > Requests-as-alternatives-to-Cmds approach. Rather than building a command > directly, we would build requests that could be similarly mapped with > routing functions as they propagated up through the model from update > functions. At the top level, we would maintain a dictionary mapping request > ID's to decode-and-route functions and turn the request itself into a > command to post to the upstream channel. The listener on the socket would > see the responses coming back and look in the dictionary for a > corresponding entry. > > That all seems pretty straightforward. But note that the model now > contains a dictionary of decode-and-route functions. Is there a solution > that avoids this and doesn't gum things up significantly in other ways? > > Mark > > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
