[elm-discuss] Re: Web components vs. Native

[Maxwell Gurewitz]

Hey Rupert.  I'm not comparing web components to ports.  Of course ports 
are a standard, important part of elm.  My comparison is to native elm, 
which is different.  For example,

https://github.com/elm-lang/persistent-cache/tree/master/src/Native

Ports can't break the debugger's guarantees because the debugger doesn't 
run port code during replays.

On Friday, March 24, 2017 at 4:29:53 AM UTC-7, Rupert Smith wrote:
>
> On Wednesday, March 22, 2017 at 11:57:22 PM UTC, Maxwell Gurewitz wrote:
>>
>> Hi all.  I'm creating this thread to discuss the relative merits of web 
>> components and native code.
>>
>
> One of the merits is that you can avoid ports to some extent, because a 
> web component can be set up by passing it attributes or properties, and can 
> tell your Elm code about events through custom event handlers and using 
> Html.Events.on. 
>
> Perhaps this is why you get the impression that web-components are favored 
> over ports?
>
> I think the custom event handler can be very useful and save on Elm coding 
> needed to set up a subscription. Of course, there is no need to use the web 
> components standard to do these things a minimal amount of javascript can 
> be used instead.
>
> I think you are somehow getting the wrong impression that web-components 
> are favored. They can be problematic as mentioned already - placing them 
> within the DOM that Elm controls can lead to them being re-rendered and 
> losing their internal state. There is an impedance mismatch between 
> web-components which are object oriented and encapsulate state and 
> functional Elm code that does not.
>

-- 
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Web components vs. Native

[Maxwell Gurewitz]

What room are you in in the elmlang slack peter?  Web components elements 
have lifecycle hooks, including hooks which will be fired when the 
component is attached/rendered.

https://www.webcomponents.org/community/articles/introduction-to-custom-elements

They can produce any number of effects in these hooks: throw exceptions, 
trigger alerts, utilize random numbers, make http requests etc.  To 
re-iterate, these effects can cause web components to break the replay 
functionality of elm-debugger, as the web components are repeatedly 
re-rendered.

On Thursday, March 23, 2017 at 4:15:20 AM UTC-7, Peter Damoc wrote:
>
> On Thu, Mar 23, 2017 at 9:33 AM, Maxwell Gurewitz <maxth...@gmail.com 
> > wrote:
>
>>
>> > You will be able to use a web component ONLY in the view will be as 
>> pure as it is right now. 
>>
>> Unless I'm misunderstanding you, I'm pretty sure this isn't true.
>>
>
> Wonderful! Maybe you can help me with an exploration. 
> I'm aiming to create a proof of concept where a web-component could be 
> used in such a way that it behaves like a "mutation as service". (I'm 
> hoping to not be able to do it) 
> Please contact me on Slack if you are interested. 
>  
>  
>
>> Any violation of purity that is available to native code is also 
>> available to web components, given that web components can execute 
>> arbitrary js when they render.  That's why we have silly non-presentational 
>> web components like polymer's ajax component 
>> https://github.com/polymerelements/iron-ajax.  
>>
>>
> As per the above, I would love to see a proof of concept that shows this. 
> In JS you have an imperative way of programming and you can do certain 
> things that are just impossible in the Elm world. 
>  
>
>> > Again, I don't think that the use of web components is encouraged. 
>>
>> Why do you feel that way?  My impression is that writing native code is 
>> discouraged (thus the lack of documentation, and Evan's elm-dev posts on 
>> native code etc.) while the use of web components is encouraged (thus 
>> Richard's section on web components in Elm in Action).  
>>
>  
> I have spoken with Richard and this is a very sensible topic as there are 
> potential nasty consequences that might not be obvious from the start. 
> Web components do have their role to play and I'm assuming that Richard 
> might touch on his book on this BUT the topic has not been fully fleshed 
> out. 
>
>
>
> -- 
> There is NO FATE, we are the creators.
> blog: http://damoc.ro/
>

-- 
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Web components vs. Native

[Maxwell Gurewitz]

Hey Peter,

> You will be able to use a web component ONLY in the view will be as pure 
as it is right now. 

Unless I'm misunderstanding you, I'm pretty sure this isn't true.

Any violation of purity that is available to native code is also available 
to web components, given that web components can execute arbitrary js when 
they render.  That's why we have silly non-presentational web components 
like polymer's ajax component https://github.com/polymerelements/iron-ajax. 
 

> Again, I don't think that the use of web components is encouraged. 

Why do you feel that way?  My impression is that writing native code is 
discouraged (thus the lack of documentation, and Evan's elm-dev posts on 
native code etc.) while the use of web components is encouraged (thus 
Richard's section on web components in Elm in Action).  




On Wednesday, March 22, 2017 at 10:35:18 PM UTC-7, Peter Damoc wrote:
>
> To my understanding there is no promotion of the web components as a 
> standard way of interacting with JS. 
> They are mentioned as a way of encapsulating complex JS that might fail. 
> In other words, one could use some complex widget (like google-maps) and 
> get some functionality into their elm app *fully aware* of the risks 
> involved. 
>
> 1. Type safety:
>
> There is none with web components BUT, you do get a nice border control 
> and black-box encapsulation from the perspective of Elm. 
> It very similar to using ports only that from my perspective, the 
> interaction is nicer. 
>
> 2) Purity guarantees
>
> You will be able to use a web component ONLY in the view will be as pure 
> as it is right now. 
> You will not be able to interrogate the web component, you will have to 
> subscribe to its events just like you subscribe to onClick on a button. 
> This is very different from Native that you can use all over the place.
>  
> 3) Versioning guarantees 
>
> web components are not part of the Elm ecosystem and so, they are not and 
> will never be covered by elm-package. Maybe after we get the ability to 
> describe web-components in pure Elm, you will be able to find 
> web-components in elm-package. 
>
> So if the main motivation for discouraging the use of native is to promote 
>> safety, why encourage the use of web components?
>
>
> Again, I don't think that the use of web components is encouraged. 
> They are only an escape hatch that is available to Elm programmers. 
>
> These being said, I do believe that the mechanism of web-components has a 
> lot to offer to Elm. 
>
> I have played with some prototypes and the experience of writing 
> web-components in Elm is quite lovely. 
> In an ideal world, we don't use  in Elm but rather 
>  becomes an Elm implemented web-component. 
> The web-component standard could be the official way to embed and interact 
> with Elm apps. 
>
>
>
>
>   
>
> On Thu, Mar 23, 2017 at 1:57 AM, Maxwell Gurewitz <maxth...@gmail.com 
> > wrote:
>
>> Hi all.  I'm creating this thread to discuss the relative merits of web 
>> components and native code.
>>
>> It's my perception that web components are being promoted within the elm 
>> community as a standard means of javascript interop, while writing native 
>> code is discouraged.  In particular, Richard Feldman has recently added a 
>> section on web components to his book Elm in Action (great book btw, you 
>> should totally buy it!), and I'd love to get his feedback.
>>
>> I don't understand this preference for web components over native code.  
>> As far as I can tell web components and native code lack all of the same 
>> safety guarantees.
>>
>> 1) Type safety:
>>
>> Both native code, and js inside of custom web components have the 
>> potential to raise exceptions, or produce invalid results due to a lack of 
>> type safety.
>>
>> 2) Non-determinacy:
>>
>> Both native code and js inside of custom web components have the 
>> potential to introduce non-determinacy.  You can imagine that the google 
>> maps web component might receive a 500 status response from google during 
>> an outage, or the author of the component might simply include a 
>> Math.random.  This will violate the guarantees made by the elm-debugger 
>> which disables port code from running for exactly this reason, which could 
>> prevent you from being able to reliable replay UI interactions.
>>
>> 3) Versioning guarantees:
>>
>> Neither native code nor web components can be published in elm-package, 
>> and they both include javascript, so neither can benefit from elm's semver 
>> enforcement.
>>
>> Now I understand that web components may be more 

[elm-discuss] Web components vs. Native

[Maxwell Gurewitz]

Hi all.  I'm creating this thread to discuss the relative merits of web 
components and native code.

It's my perception that web components are being promoted within the elm 
community as a standard means of javascript interop, while writing native 
code is discouraged.  In particular, Richard Feldman has recently added a 
section on web components to his book Elm in Action (great book btw, you 
should totally buy it!), and I'd love to get his feedback.

I don't understand this preference for web components over native code.  As 
far as I can tell web components and native code lack all of the same 
safety guarantees.

1) Type safety:

Both native code, and js inside of custom web components have the potential 
to raise exceptions, or produce invalid results due to a lack of type 
safety.

2) Non-determinacy:

Both native code and js inside of custom web components have the potential 
to introduce non-determinacy.  You can imagine that the google maps web 
component might receive a 500 status response from google during an outage, 
or the author of the component might simply include a Math.random.  This 
will violate the guarantees made by the elm-debugger which disables port 
code from running for exactly this reason, which could prevent you from 
being able to reliable replay UI interactions.

3) Versioning guarantees:

Neither native code nor web components can be published in elm-package, and 
they both include javascript, so neither can benefit from elm's semver 
enforcement.

Now I understand that web components may be more ergonomic than equivalent 
native code in certain situations e.g. in the google maps case, but they 
don't seem any more or less safe than native code.  Furthermore, they 
impose the cost of an additional build system (bower) and polyfills.

So if the main motivation for discouraging the use of native is to promote 
safety, why encourage the use of web components?

Thanks.

-- 
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: How to integrate JS library that changes DOM (eg KaTeX)

[Maxwell Gurewitz]

You're going to want to use

http://package.elm-lang.org/packages/elm-lang/html/2.0.0/Html-Keyed

On Tuesday, February 14, 2017 at 5:41:11 PM UTC-8, vis...@stanford.edu 
wrote:
>
> Hi all!
>
> Just started using Elm and I'm really liking it.
>
> One question I had is whether it is possible to integrate a library like 
> KaTeX that actually modifies the content of a DOM element that is 
> controlled by Elm.
>
> If so how would I do that? React/Mithril have ways of interrupting the 
> rendering lifecycle to squeeze in your own behavior, but how does Elm allow 
> for that?
>
> Another simple way to do it is to render a script tag, like:
>
> 
>  KaTeX.render('...', document.getElementById('katex')) 
>
> I can render a script element, but I need to force elm to re-render the 
> script tag each time, and for that, React allows you to put a key 
> attribute. Is there something similar in Elm?
>
> There are a lot of other widget-like js libraries that I wanted to include 
> on my webpage, like musicalabc (abcjs) or mermaid.js, or highlight.js, etc.
>
> Any ideas? Thanks!
>
> Vishesh
>

-- 
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Image lazy-loading?

[Maxwell Gurewitz]

You'll have to have use keyed elm nodes to get this to work.

On Tuesday, January 17, 2017 at 9:10:22 AM UTC-8, Tomáš Znamenáček wrote:
>
> Now that I think of it, this is even more tricky, right? Because the Elm 
> runtime juggles the DOM nodes as it sees fit, easily making them go out of 
> sync with the Echo.js library. So what should I do to make images 
> lazy-load? Thank you,
>
> T.
>

-- 
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Best [ractices for listening to EventSource (Server-Sent Events)

[Maxwell Gurewitz]

You can use the elm websockets library, or ports.

On Wednesday, September 14, 2016 at 3:16:10 AM UTC-7, Erwan Queffélec wrote:
>
> Hi,
>
> I'm trying to find the cleanest possible way of subscribing and receiving 
> server side events (SSE) (
> http://www.html5rocks.com/en/tutorials/eventsource/basics/)
>
> So far I found this 
> https://stackoverflow.com/questions/35144530/how-to-capture-server-events-in-elm
>
> And this (code contributed by the SO answer author): 
> https://github.com/lukewestby/elm-http-event-source
>
> Is there any built-in way of doing this with elm yet ? Is that somewhere 
> on the roadmap ?
>
> Regards,
>
> Erwan
>

-- 
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Pairing Session Video: Josh Adams and Luke Westby pairing on server-side-validations

[Maxwell Gurewitz]

I think the video link is broken.

On Friday, September 9, 2016 at 7:33:36 AM UTC-7, Josh Adams wrote:
>
> Yesterday, I got the chance to spend nearly 2 hours pairing with Luke 
> Westby.  We did this: 
> https://www.dailydrip.com/topics/elm/drips/server-side-validations​
>
> *tl;dw*
>
>- I showed him where http://github.com/knewter/time-tracker had gotten 
>this week with live validation merging elm-simple-form and elm-mdl.
>- Then we added a server-side validation to the API that the 
>client-side validators couldn't help with (unique field constraint in 
>database table).
>- Finally, we merged the server-side validations in nicely with the 
>client-side validations and made sure the UX was pleasant. 
>
> 
>   - I *hate it* when UX people don't fix these simple things.
>
>
> Anyway, I hope you enjoy watching it!  *I know there's tons to refactor* 
> but I was (trying to stay) focused on just getting the ugly dirty thing out 
> the door.
>
> :heart:
>
> -Josh
>

-- 
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Task ports: A proposal to make it easier to integrate JS with Elm.

[Maxwell Gurewitz]

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
>>

[elm-discuss] Re: Task ports: A proposal to make it easier to integrate JS with Elm.

[Maxwell Gurewitz]

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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Task ports: A proposal to make it easier to integrate JS with Elm.

[Maxwell Gurewitz]

I've had the same idea.  Really hope this gets noticed!

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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Bubbling Http Errors from Nested Components

[Maxwell Gurewitz]

Josh, I'm running into a similar problem.  I want to trigger a global error 
handler whenever any of my components error, (a 401 from session expiration 
for example), but I want to be able to spread out my api throughout my 
components.

On Tuesday, July 5, 2016 at 7:53:29 AM UTC-7, Josh Adams wrote:
>
> I would handle this entirely differently, personally.  I'm inclined to 
> have an API TEA component as a child at the Root, and send up messages 
> requesting API calls to it.  I would never spread my API requests out 
> through components.
>
> That's just me though - I know other people handle this way differently. 
>  Would love to hear any suggestions from more experienced folks re: this :)
>
> -Josh
> http://www.dailydrip.com/topics/elm
>
> On Tuesday, July 5, 2016 at 7:46:16 AM UTC-5, Erik Lott wrote:
>>
>> My app has several layers of nested components. Various components 
>> throughout the tree will need to interact with our API via http requests. 
>> If any API request returns a 401 - Not Authorized error, or a Timeout 
>> Error, the error needs to bubble up to the root component where is can be 
>> handled appropriately.
>>
>> What is the most idiomatic way of dealing with this? 
>>
>> *1. Parent should pattern match against important child messages*: 
>> Reference 
>> 
>> This could work, but would be unreasonable in this case. The root 
>> component would need to match against every failing api http request made 
>> by every child, grandchild, great-grandchild, etc, component in the tree. 
>> If a single pattern is missed, the app would be in an error state, so this 
>> is prone to mistakes.
>>
>> *2. Nested Components return additional info from the "update" function*: 
>> Reference 
>> 
>> Each component returns an additional value from its update function like 
>> this:
>> update : Msg -> Model -> (Model, Cmd Msg, SomeInfo)
>>
>> The parent component could inspect the returned "SomeInfo" value from its 
>> direct children, and act on that information if necessary.  In my case, any 
>> nested component that makes http requests to our API would be responsible 
>> for returning a APINotAuthorized and APITimeout value to its parent, and 
>> its parent would do the same, until the error has bubbled up to the root 
>> component.
>>
>>
>> Option 2 is simple and robust, and can be used to pass messages of any 
>> type, for any situation... but I'm wondering if I'm missing an obvious 3rd 
>> solution?
>>
>

-- 
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: virtual-dom hooks

[Maxwell Gurewitz]

You can implement post render hooks using requestAnimationFrame.  Elm 
guarantees that the dom changes corresponding to an update will be rendered 
after a requestAnimationFrame. 
 Use https://github.com/elm-lang/animation-frame

On Friday, March 25, 2016 at 8:03:39 AM UTC-7, San Gillis wrote:
>
> Hi,
>
> I built a simple integration of Highcarts.js in Elm using virtual-dom 
> hooks. I wrote a blog post about it here:
>
> http://sgillis.github.io/posts/2016-03-25-highcharts-integration-in-elm.html
>
> As I understand Evan is working on an improved Native system for future 
> versions of Elm, but I thought this might be an interesting approach 
> meanwhile. Has anyone else used this? What do you guys think about this 
> approach? Are there any plans to expose virtual-dom hooks at some time in 
> the future?
>

-- 
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.