It'd be more in line with community standards if the callback followed the
node convention
App.ports.myTaskFunc = function(val, cb) {
cb(null, val + 2);
}
On Wednesday, August 24, 2016 at 11:57:04 AM UTC-7, James Wilson wrote:
>
> It wouldn't be hard to provide a promise shim, although I'm not sure how I
> feel about that.
>
> Callbacks would be the well supported option, although the interface to
> promises maps better. Promises can only resolve/reject once, always return
> something, and the function attached to the task port could just return a
> plain old value too, which would be equivalent to resolving a promise
> immediately with that value. This means that for synchronous calls the user
> can just provide a regular function to the JS side of the task port and not
> do anything Promisy at all. If we want to provide callbacks instead I would
> be tempted to provide 2 - one for resolve and 1 for rejection, and then add
> the promise logic (first one to be called wins) behind the scenes.
>
> In the promise scenario, these are all valid:
>
> App.ports.myTaskFunc = function(val){
> return (val + 2) //equivalent to returning a Promise that is resolved
> to (val+2) immediately
> }
>
> App.ports.myTaskFunc = function(val){
> return new Promise(function(resolve){
> resolve(val+2)
> reject("err") // this is ignored since we've already resolved.
> });
> }
>
> App.ports.myTaskFunc = function(val){
> return Promise.resolve(val + 2)
> }
>
>
> And the equivalent callback style might look like:
>
> App.ports.myTaskFunc = function(val,resolve,reject){
> resolve(val+2);
> reject("err") // this is ignored since we've already resolved.
> }
>
>
>
>
>
> On Wednesday, 24 August 2016 18:42:16 UTC+1, Maxwell Gurewitz wrote:
>>
>> My only comment would be that the interface should not rely on promises,
>> which are not supported by IE. Instead it should use node style callbacks.
>>
>> On Saturday, August 13, 2016 at 8:31:07 AM UTC-7, James Wilson wrote:
>>>
>>> The problem
>>>
>>> ports as they stand are fundamentally incompatible with Tasks. Being
>>> backed by Cmd's, they are harder to compose. A frustration of mine is that
>>> often we are directed to "just use ports" when a proper interface to some
>>> native API is not yet available, but this leads to our Msg types growing
>>> and more significant changes being required when eventually the proper
>>> interface is made available.
>>>
>>> Also, many JS interop things I find myself wanting to do are
>>> fundamentally one-shot functions which I expect a result back into Elm from
>>> immediately, or otherwise just want to compose with other Task based
>>> things. Some examples that come to mind of one-shot tasks you may want to
>>> compose rather than use the streaming interface that ports provide:
>>>
>>> - Getting items from local/sessionStorage
>>> - .. really, most things involving working with the Web API that
>>> arent yet implemented in Elm.
>>> - Embedding JS widgets into Elm elements
>>> - Using a JS library for doing things like hashing passwords or
>>> obtaining some data back from some custom service
>>> - Interacting with things like Electron for creating apps that can
>>> run in the desktop and interact with the filesystem etc.
>>>
>>>
>>> The solution
>>>
>>> Task ports. The idea is that these are defined the same way that Ports
>>> in elm currently are, but they return a Task type rather than a Cmd or Sub
>>> type. On the JS Side, we attach a function to the Elm app that returns a
>>> Promise, and on the Elm side we wait for the Promise returned to reject or
>>> resolve, and marhsall the error or result from the promise into the error
>>> or result type required by the Task type of the port.
>>>
>>> Let's see how this might work:
>>>
>>>
>>> *Ports.elm:*
>>>
>>> port apiSession: Task String SessionId
>>>
>>>
>>>
>>> *Main.elm:*
>>>
>>> import Ports
>>> import Json.Decode as Decode
>>> import Task exposing (andThen)
>>>
>>>
>>> -- get an API session from JS land and make an http request using it
>>> -- given some path and a decoder to decipher the result:
>>> apiRequest : String -> Decoder a -> Task ApiError a
>>> apiRequest path decoder =
>>> let
>>> headers sessId =
>>> [ ("Content-Type", "application/json")
>>> , ("MyApp-SessionId", sessId)
>>> ]
>>>
>>>
>>> req sessId = Http.send Http.defaultSettings
>>> { verb = "POST"
>>> , headers = headers sessId
>>> , url = path
>>> }
>>>
>>>
>>> decodeResponse res = Decode.decodeString decoder -- ...handle error
>>> etc
>>> in
>>> Ports.apiSession `andThen` req `andThen` decodeResponse
>>>
>>>
>>> *App.js:*
>>>
>>> Elm.Main.ports.apiSession = function(){
>>> return new Promise(function(resolve,reject){
>>>
>>>
>>> var sess = localStorage.getItem("sessionId");
>>> if(!sess) reject("NO_SESSION");
>>> else resolve(sess);
>>>
>>>
>>> });
>>> }
>>>
>>> var app = Elm.Main.fullscreen();
>>>
>>>
>>>
>>>
>>> Here, we use a tiny bit of JS to access localStorage and pull out a
>>> session ID. This function is used whenever the apiRequest Task is performed
>>> in Elm, and composes nicely into our apiRequest without the need for a
>>> complicated effect manager or threading a sessionId through everywhere just
>>> because we need to get it from a Cmd based port.
>>>
>>> One of the nice things about this is that there is minimal refactoring
>>> to do for those things that do eventually receive coverage in the Elm Web
>>> API - you're just swapping out Tasks for other Tasks. As the Web API will
>>> always be changing, I think that having a nice way to make JS polyfills
>>> like this will always have some value, let alone for interacting with
>>> libraries written in JS that haven't or won't ever be ported to Elm.
>>>
>>> Elm would continue to make the same guarantees as with other ports; if
>>> the task port can't marshall the response back into Elm an error would be
>>> thrown along the same lines as is currently done via ports.
>>>
>>> Summary
>>>
>>> - regular ports only let you send data off or receive data back, not
>>> both.
>>> - Cmd's and Sub's are not composable
>>> - Task based ports allow you to create a new Task that is backed by JS
>>> - Task based ports allow for better composition and less friction when
>>> the backing JS is eventually implemented in Elm.
>>>
>>> I'd love to hear what people think about this. Perhaps I'm missing some
>>> big issues with the idea for instance, or maybe it's an awesome idea :)
>>> What do you all think?
>>>
>>>
--
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.
