> > Sure, I could abuse it to call a stateful js ap
Which you can currently do with Cmd ports! We'd just want to wrap it in some type like Task or Cmd, and then it would be nicely segregated from pure code. On Wed, Dec 14, 2016 at 10:00 AM, Desmond D'Souza <[email protected]> wrote: > I would love to be able to make synchronous functional calls to js and get > a Result back. > > Taking simple clean synchronous functional code (e.g. if it were all in > Elm), and being forced to chop out bits into async calls with async Msg > callbacks (just because it is not all in Elm) impacts my code in unpleasant > ways: > > 1. weird async bugs: will my originally sync call to *layout(graph)* get > the layout answer back *after *the user has switched to another graph? > 2. pollution of model and update: > - I need to stuff into my model bits that were simple transient > local variables before, and maintain those extra bits everywhere in my > code. Forget to clear them somewhere, and chunks of my code like another > update branch or a view function, think I have a current graph waiting > for > a layout. > - I add more checks into my update to deal with possibly getting > intervening unrelated async inputs > 3. API bloat: why does *AndHereIsYourLayoutBack* need to be part of > my API, when that is already explicit through the outgoing call mechanism > (e.g. via something like a synchronous port, or some alternative) > > I think #1 would be somewhat alleviated by synchronous tasks from this > thread > <https://groups.google.com/forum/?fromgroups#!topic/elm-discuss/ejv98qDe7Oo>, > but #2 and #3 remain. > > Properly supporting this use case would be good for Elm. Sure, I could > abuse it to call a stateful js api, causing problems if the Elm compiler > moves expression evaluation order around, hence I use some *unsafe* marker > either as an annotation to myself or to the compiler. > > > On Wednesday, December 14, 2016 at 4:48:06 AM UTC-6, Rupert Smith wrote: >> >> >> >> On Tuesday, December 13, 2016 at 3:42:23 PM UTC, Joey Eremondi wrote: >>> >>> the elm package repo would very quickly get poluted with js code that >>>> causes runtime exceptions >>> >>> >>> But, Tasks have error handling built into them. We could do something >>> similar with synchronous code, just catch any exceptions thrown, and treat >>> the value in Elm as something like a Result. >>> >> >> > the elm package repo would very quickly get poluted with js code that >> causes runtime exceptions _* and is not portable *_ >> >> Result would work, but the not portable bit is equally impoertant. >> >> > -- > 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.
