@Max: I think Eve does, what you want. I mean uniting events, http requests, model access. They are all accessed by "search". Look at this page: http://docs.witheve.com/handbook/blocks/ (I know very little about Eve. I was just reading this page)
On Thursday, November 24, 2016 at 7:17:27 PM UTC+1, Max Goldstein wrote: > > Regarding simple type systems, experiments, and language features for > library authors -- finding the right abstraction is hard. In 0.18, there's > an HTTP abstraction, so you can run requests in parallel (but not arbitrary > effects: racing a file read and a file delete is a bad idea!). Then there's > an abstraction for arbitrary effects, Task, which can be chained with > andThen. Finally there's Cmd which is more restricted and represents the > final unit of work to be done by the runtime. The most sophisticated thing > you can do is map over its return value (not the work itself), usually to > wrap it so you can identify what happened. But importantly, the preferred > way to run an HTTP request is to turn it directly into a Cmd. You can turn > it into a Task, and a Task into a Cmd, but that's an escape hatch for > experts. > > Back to the larger goals: I think it's fair to say that we want to be able > to write webapps/SPAs in Elm. That is, we want it to replace Angular, > Ember, React+Flux, etc. > > Evan has said that he wants to wrap the "web platform", and as a result of > that, we have access to most web primitives but not nice framework > abstractions. We have virtual DOM but resuable UI components. We have HTTP > but no models (like Ember Data or Rails, not the Elm model that holds all > your state). That is, Elm is really good at computation and the ability > extract functions is incredibly useful. But things stop working when you > look at the inputs and outputs of a webapp, and they are primarily HTML and > HTTP (also the current time, randomness, and a few others). > > So I think what we need is the ability to abstract over HTTP with models, > and to abstract over HTML with reusable components. The former seems really > hard. The former seems hard only if you need to hold state in your > component; maybe we'd have some luck trying to make "components" that are > actually just functions? > -- 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.
