It was just something that bugged me when I first saw it in the examples,
and I just came to the realization of why. And I am wondering out loud what
it look like if they were separate things.
In your example case, you could make a 3rd command that did the issued a
new message InfoConnectIdAssigned to separate the model bit out. The
tradeoff is isolation of model changes vs increased boilerplate (issuing a
no-effect command). I think a shortcut method could be in order like
Cmd.none, but something like Cmd.fromMsg.
On Thursday, August 11, 2016 at 12:53:16 PM UTC-5, OvermindDL1 wrote:
>
> I guess what you are proposing is separating a Message into a 'commands'
> and 'update' callbacks? That could work well too... I could add that as
> an option to my ProgramEx testing library (where I test with extra
> callbacks) if you want to play around with it? Do you propose that
> `update` would be `Msg -> Model -> Model` and `command` would be `Msg ->
> Model -> Cmd Msg, running in sequence of command before update? I can see
> a lot of them having a lot of duplicate code though, but I guess that could
> be removed from my currently testing `filters` callback to clean up the
> message into more pure stateful messages. Though if I did that I really
> think I would want to make two different message types, one for filters and
> one for consuming, however that may make larger API changes than would be
> easy... What precisely would you want it to look like?
>
>
> On Thursday, August 11, 2016 at 11:48:21 AM UTC-6, OvermindDL1 wrote:
>>
>> Just as an aside, but I quite often return a mutated model *and*
>> commands, such as this for the shortest example I am finding:
>> ```elm
>>
>> InfoConnect uid ->
>> ( { model | uid = uid }
>> , Cmd.batch
>> [ connect_roomlist 0
>> , connect_roomlist uid
>> ]
>> )
>>
>> ```
>> So when we connected to the server, got an InfoConnect message back with
>> the unique ID of the user, they then are allowed to connect to both the
>> public and their personal room lists, so I submit those connection requests.
>>
>>
>> On Thursday, August 11, 2016 at 11:37:48 AM UTC-6, 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.
