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 

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?


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.

Reply via email to