It's easy to find concrete issues - a whole class of issues would be solved with task ports. All problems that require interop between Elm and JS, where a message from Elm to JS must be correlated with a message from JS to Elm. The async request-response pattern. Like callbacks or Promises in JS land.
- Interacting with new web APIs that are not yet supported by Elm: - IndexedDB, LocalStorage, SessionStorage - Messages to/from Web Workers and Service Workers - Sending two messages to the same outgoing port, receiving two responses on an incoming port, the responses may come out-of-order, correlating which response belongs to which outgoing message With task ports, one can write less JS, more generalised, and then build business logic in Elm on top of that generic JS code. With the standard setup today, workarounds will generally involve more business logic on the JS side. Instead of using the elm-xxx library for example, for web API xxx (localstorage for example, where Elm development has stalled), users can make their own ad-hoc bridge, get Tasks on the Elm side, and compose these Tasks into more complicated Tasks. Where most of the complexity ends up in Elm, and as little as possible in JS. onsdag 24. august 2016 00.21.38 UTC+2 skrev Tim Stewart følgende: > > > I know, Elm design decisions are based on concrete use cases not on waffly > hand-waving. I'll try and find time to write one up. > >> >>> -- 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.
