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.
