Thinking about this further, yes, one can wrap the logic to talk to a pair of ports in a way that makes them work like commands that actually include responses. Doing so, however, requires the following departures from standard Elm practice:
1. Communicate up from update functions using lists of out messages rather than commands. We need to do this so that we can route the requests to the logic handling the ports. (In practice, I find this pattern helpful in other ways as well, but it does depart from standard Elm practice and it requires more plumbing work for each point where modules get glued together.) 2. Store (tagging) functions in the portion of the model handling the ports so that results can be tagged for delivery when they come in through the subscription port. This goes against the "don't store functions in the model" advice and makes it unsafe to use the equality operator with ones model — though I suspect that in practice it would prove to be safe. This is essentially the process of building and using what I referred to as a pseudo-effects manager. If anyone really wants example code, I can try to get some written up. If persistent cache doesn't become available soon, I may be writing this anyway to handle the logic for talking to local storage. But even with this "solution" in hand, we're still not in a great position to address the issue of moving performance critical code out of Elm and into JavaScript. The above design can wrap that logic in something that behaves much like a command, but those and this are awkward to thread through a computation. In comparison, when I've tried taking synchronous algorithms and breaking out pieces into tasks — e.g., to access a database — the refactoring process is actually pretty straightforward. So, having some official, documented way to create JavaScript-based tasks would still be a huge win in opening up an escape hatch for performance issues and access to other functionality. Mark > On Dec 28, 2016, at 12:06 AM, Mark Hamburg <[email protected]> wrote: > > Ports as they exist in 0.18 do not appear to offer this. If you want to make > a request and receive a response, you need to make the request through a > command port and receive the response through a subscription port. If you > want to make multiple requests and receive multiple responses, you must do > something to match responses with the code waiting for them which generally > means generating and managing some form of ID's. The code to do that starts > to look a lot like an effects manager, but the documentation discourages > writing those. One could probably make this work via an out message based > design with a pseudo-effects manager at the top level to manage ID's and talk > to the ports but note that this pseudo-effects manager will be part of the > model and will be storing functions — something that there is also advice to > avoid doing. -- 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.
