> * A "foreign" value type that could capture a reference coming from 
JavaScript to be handed back in other calls.

We already have that with Json.Encode.Value, and it can be passed to from 
javascript: see this example for Google maps 
<http://simonh1000.github.io/2016/12/elm-ports-google-maps/>, which I 
copied from how Evan built websockets

Simon


On Thursday, 8 December 2016 19:28:22 UTC+1, Mark Hamburg wrote:
>
> 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] 
> <javascript:>> 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] <javascript:>.
>>
>>
>> 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.

Reply via email to