Would it help if there were a standard mechanism to invoke JavaScript code as a task (or equivalently to make JavaScript code available as a task)? When the goal is to do some external computation, ports feel awkward as a mechanism. Something like:
port parseMarkdown : String -> Task Error Json.Decode.Value (I'm handwaving here because I don't know what Error should be.) One would wire up parseMarkdown in much the same way as other ports possibly using something like JavaScript promises to allow for long computations. The arguable downside to this sort of interop is that it doesn't really provide a good way to build modules that can be distributed to others since the ports need to be connected in the app launch code. But that's true of other port types as well. Mark On Tue, Dec 6, 2016 at 2:14 PM, 'Rupert Smith' via Elm Discuss < [email protected]> wrote: > On Tuesday, December 6, 2016 at 7:32:49 PM UTC, Rupert Smith wrote: >> >> On Tuesday, December 6, 2016 at 5:18:04 PM UTC, Wil C wrote: >>> >>> So now, either I write a ports for commonmark.js, or I write it as a >>> native module. I asked about it here >>> <https://groups.google.com/forum/#!topic/elm-discuss/Kd53qnKY-io> with >>> no answers. >>> >> >> I think if you write it as ports or native, you'll still need to map the >> AST between javascript and Elm. As a native module that could be done with >> a Decoder or by constructing the Elm AST in native code with Javascript. >> Perhaps Decoders are not so bad? >> >> I don't think a parser is a side-effect. A parser is a pure function from >> String -> Ast, with no side effects. >> > > The thing about ports for something like this is it feels a bit unnatural > to invoke the port resulting in a Cmd. Then you'll need a subscription port > to get the result back in, and have that pass it to your update function > from where you can take it and place it in the model. That doesn't feel > like a good way to call a function : String -> Ast. > > I'd say the best solution is to implemented your parser in pure Elm. But > if that is too much work, just hack together a native module that calls out > to commonmark.js. You won't be able to publish your native module to elm > packages, but that's ok, perhaps no-one else really wants your markdown > with embedded SQL anyway, and if they do there is always > elm-github-install. Some time down the road when you really need to share > this amazing library, redo it in pure Elm. > > -- > 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. > -- 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.
