I was talking about this further with my coworkers and we more or less
agreed that the key things that could help with Elm's interface to
JavaScript were:
* Task ports. Tasks are a building block in a way that commands are not.
Forcing all external interactions to be asynchronous makes it more clear
that one is stepping outside and code could fail.
* A "foreign" value type that could capture a reference coming from
JavaScript to be handed back in other calls. For example, though not a
great JavaScript example, this could be a database connection. All
operations on the database would occur via tasks. We just need an easy way
for Elm to hold the handle to the database connection. This functionality
would be better if the foreign types could be distinguished within Elm in
their declaration — e.g.
port type DBConnection
("port" reads wrong but I was avoiding introducing a new keyword.)
That said, one could also just use Foreign as a base type and use Elm code
wrap it in more meaning for the type checker:
type DBConnection = DBConnection Foreign
This, however, probably makes it harder to use the types safely in the task
APIs.
Would those two features address everything needed? No. In particular, port
wireup inhibits creating libraries. But it would make it much more
straightforward for any individual project to build interfaces to
JavaScript-based functionality.
Mark
On Thu, Dec 8, 2016 at 9:27 AM Vojtěch Král <[email protected]>
wrote:
>
> Dne úterý 6. prosince 2016 23:14:06 UTC+1 Rupert Smith napsal(a):
>
> 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.
>
>
> This resonates with me very much. This is _exactly_ the reason why I made
> The Elm Alienation post on Reddit:
> https://www.reddit.com/r/elm/comments/5g3540/the_elm_alienation/
>
> I also wanted to ask here about the status of the Native API but I'm
> seeing you guys already inquired.
>
> Forcing people to rewrite everything in Elm is a terrible idea.
>
>
> Dne středa 7. prosince 2016 17:18:37 UTC+1 Mark Hamburg napsal(a):
>
> 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)?
>
>
> Yes! Very much! If this happened, I'd definitely revisit the decision to
> leave 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.
