Thanks for the pointer. We hadn't dug into Phoenix deeply enough to see that it has a request/response architecture at the channel level already, so that was useful news. On the other hand, what that basically does is says that for the special case of Phoenix channels where the need for a callback is already defined and where the effects manager supports it, we can move the need to store functions out of the model and into the effects manager. Great for that special case. But what if I needed to use web sockets instead of Phoenix? My general point is that one doesn't have to dig that deeply to find places where storing functions in the model is useful. On the other hand, many of those use cases do look like effects managers which might suggest that the answer is to write effects managers — except the the documentation also discourages doing that.
On Sat, Oct 15, 2016 at 2:38 AM, Oliver Searle-Barnes <oli...@opsb.co.uk> wrote: > 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. > -- 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.
