Given the existence of Process.sleep, the argument that tasks have to return at 
some point and we couldn't guarantee that from JavaScript seems incredibly weak.

Given that effects manager development seems to have ground to a halt — Local 
storage? Phoenix? — it seems pretty vital for a language that talks up 
integration with JavaScript as one of its top features that there be a 
straightforward way to extend it with JavaScript. Command and subscription 
ports don't qualify because they don't provide a clean way to match requests to 
responses.

Mark

> On Apr 13, 2017, at 12:32 AM, Martin Norbäck Olivers <norb...@gmail.com> 
> wrote:
> 
> An interesting read!
> However it seems they sort of talk beside a big point of "task ports". My 
> example is not so much communicating with the outside world in a general 
> sense but more communicating with the browser, using in Elm unimplemented 
> browser APIs.
> 
> The responsibility would be completely on the javascript side to return a 
> result, but right now the only way to call these API:s is to write "Native" 
> code, or to make "dual ports", one for sending a command, the result of which 
> is then returned in a subscription and need to be paired with the call 
> without any guarantee of the order of the results etc.
> 
> The question is, why is it worse to have a Task not return a result than to 
> have this other mechanism not deliver a Msg? In both cases you'd get nothing.
> 
> Especially if Native becomes Kernel and even more unapproachable (which in 
> itself is probably a good thing), then we really need a way to have the user 
> make Tasks, or something similar to be able to use the browser APIs.
> 
> For databases, websocket-like stuff, http calls etc, that have internal 
> state, then effect modules are probably better, but for calling a function to 
> get some crypto random or to access LocalStorage? Seems like it's too much to 
> create an effect module for that, just look at the code in my example above. 
> That level of simplicity should really be available if people are going to be 
> able to use browser apis productively.
> 
> Regards,
> Martin
> 
>> Den torsdag 13 april 2017 kl. 07:32:17 UTC+2 skrev John Kelly:
>> Here's​ some context on this request / discussion: 
>> https://www.reddit.com/r/elm/comments/61trtm/hard_things_about_ports_as_task_in_elm/?ref=search_posts
> 
> -- 
> 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.

Reply via email to