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.
