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.
