One question @Evan. How are you keeping events? I would assume in Elm
structures, since you can't send union types through ports be default.
Asking in case you have some magic for transferring them out to Javascript.
The idea of writing de/en-coders for every message case (in order to
transmit or load/save in Session State) makes my brain shut down.
On Wednesday, August 17, 2016 at 2:15:49 PM UTC-5, Evan wrote:
>
> 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.
