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 [email protected]. For more options, visit https://groups.google.com/d/optout.
