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.
