On Wednesday, 28 December 2016 16:44:45 UTC+7, Peter Damoc wrote:
>
>
>
> On Wed, Dec 28, 2016 at 10:29 AM, GordonBGood <[email protected]
> <javascript:>> wrote:
>
>> It looks like the implementation of this StackOverflow answer
>> <http://stackoverflow.com/a/40334086/549617> (ignore the question and
>> relevance as it is old, but the calling a function `getParentPos ()` to
>> get some answers through some JavaScript called through a port, which
>> returns the answers through a subscription `parentPos`that fires a
>> message to update should still work. This is fine as long as there is only
>> one subscription, but as Mark says there is no Event Manager so it would
>> likely get confused if there were other subscriptions such as say
>> `Timer.every`.
>>
>> If this worked generally, it would be an easy way to transfer to a long
>> running program written in JavaScript, with that long running program able
>> to fire progress reports back and even a different completion Msg, but
>> would be fairly useless if it didn't work with other subscriptions without
>> adding a lot of code.
>>
>>
> But you can do that already with subscriptions. I mean, you can have a
> subscription for every message you want to send to your Elm program.
> To my understanding you can trigger the long running with a Cmd port and
> listen on various other Sub ports for intermediary answers and completions.
> You can use one port and push the data in a way that can generate multiple
> types of messages (progress, completion) or you can use multiple ports
> (e.g. one for progress, one for completion)
>
So you are saying we can already do the following:
type Msg = ProgProgress Progress | ProgCancelled | ProgDone Answer | Tick
port startLRP : () -> Cmd msg
port cancelLRP : () -> Cmd msg
subscriptions model =
Subs.batch
[ lrpProgress ProgProgress
, lrpCancelled ProgCancelled
, lrpDone ProgDone
, Timer.every 1000 Tick ]
port lrpProgress : (Progress -> Msg) -> Sub Msg
port lrpCancelled : (() -> Msg) -> Sub Msg
port lrpDone : (Answer -> Msg) -> Sub Msg
with the Native JavaScript as per the link for each of the ports, Types all
defined, update function handling all Msg cases, and the subscription
system will automatically handle getting each subscription to the right Msg?
Will this not cause problems with the Timer.every subscription?
If so, I take it that the only thing that stops us from being able to
trigger an event from Elm code is the Elm type checker, and that if we had
just one port out to Javascript with arguments as to which return port to
fire with what arguments (or one return port with the logic you suggested)
in a library, then we would be able to fire events from Elm code at will
using that Native "crosser" routine?
If we can do all of that, I don't see what Mark is worried about? We don't
have to have an Event Manager? What's the point of a Router/Event Manager?
Ah, I think it's to do with queue'ing messages to process later whereas
this will process them immediately?
If this all works, we could write LRP's in JavaScript or optionally move
them to Elm when it gets more efficient.
--
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.
