You can write time-travel in pure Elm this way. Indeed, and it has been done: http://package.elm-lang.org/packages/jinjor/elm-time-travel/latest (for the benefit of those you haven’t seen it, probably at least Kasey as per the follow-up message).
2016-08-17 21:15 GMT+02:00 Evan <[email protected]>: > Warning, I have not read everything here. About ignoring commands though, > think of the type of a Html.App.program > > program : { init, update, view, subscriptions } -> Program Never > > The essence of this is just a record. So you can wrap that record however > you want. Say like this: > > myProgram : ({ init, update, view, subscriptions } as details) = > { details | update = \msg model -> (fst (update msg model), Cmd.none) } > > Now you have programs that drop all commands. > > I'm in the process of revining elm-reactor to track history for exactly > the kinds of things you have in mind (testing, etc.) and I am using this > basic technique. Anyone can do this. You can write time-travel in pure Elm > this way. Make the update log all the messages it gets. > > Again, I have no idea what's happening in this discussion though, so > hopefully that's a helpful insight. > > > On Thursday, August 11, 2016 at 10:37:48 AM UTC-7, Kasey Speakman wrote: >> >> Hi all, >> >> I'm getting to know Elm. I recently read this article >> <http://marcosh.github.io/post/2016/07/09/elm-event-sourcing.html> about >> event sourcing in Elm. Essentially, the time-traveling debugger is event >> sourcing. But it's a pattern that could be used in an app for other great >> things. (Lots of literature on that in the internet. One particular >> interest of mine is producing a complete failing use case from live running >> app -- it's just all the events. Obviously wouldn't work for real-time >> apps... too many events... but for most of mine it would.) >> >> However, one thing that is a hindrance (to the TTD as well) and that has >> always bothered me about the Elm examples is this signature. >> >> update : Msg -> Model -> (Model, Cmd Msg) >> >> >> Because an update returns both a Model and Cmd, for instance, the >> time-traveling debugger "...needs to tell the runtime not to perform any >> side-effects during replay to avoid these issues"[1]. An event-sourcing >> implementation would have to figure a way to do the same without runtime >> hooks. >> >> This part of the architecture mixes concerns by returning a model and >> effects. And usually (not always) you see each message returning one or the >> other, not both. From the docs: >> >> update : Msg -> Model -> (Model, Cmd Msg) >> update msg model = >> case msg of >> Roll -> >> (model, Random.generate NewFace (Random.int 1 6)) >> >> NewFace newFace -> >> (Model newFace, Cmd.none) >> >> >> Here, Roll does an effect, but nothing with the model. NewFace returns a >> new model but no effects. You do have cases where you want to update a UI >> element when an outside effect happens, like activating a spinner when >> sending off an HTTP request. Those could still be modeled as two "Cmd"s. >> One that immediately returns a separate message affecting the model's >> spinner. And another to do the HTTP request. >> >> So it seems to me that there are really two concepts at work here. There >> are "events" which have happened and can be used completely >> deterministically, and there are commands which interface with the outside >> and may produce events. >> >> I think it's something worth pointing out and considering for the future. >> What do y'all think? >> >> Kasey >> >> [1] source <http://debug.elm-lang.org/>, section "How Elm makes this >> possible", subsection "Purity", last paragraph >> > -- > 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.
