I do like the signatures you mentioned:
`update : Msg -> Model -> Model`
`command: Msg -> Model -> Cmd Msg`
However at that point, it no longer makes sense to use the same messages
for effects and model updates. For example:
`update: Evt -> Model -> Model`
`command: Act -> Model -> Cmd Evt`
Here, using Act for commands since Cmd is already taken. Evt for events
(facts which have occurred).
The question then becomes how `view` would be affected. Html Msg doesn't
work there. If you did Html Act, then there is some boilerplate for actions
that don't have effects:
```
-- FUTURE READER: THIS IS AN EXAMPLE, NOT ACTUAL SYNTAX
command : Act -> Model -> Cmd Evt
command act model =
case act of
ChangeName name ->
Cmd.fromEvt <| NameChanged name
SubmitCustomerChanges customer ->
Cmd.batch
[ Cmd.fromEvt <| CustomerChangesSubmitted
, callServerWithCustomer customer -- or model.Customer?
]
```
An alternative is to allow Html to produce either Act or Evt. But that
feels wrong. It would be too easy to try to use only one or the other for
all the work.
On Thursday, August 11, 2016 at 1:03:47 PM UTC-5, Kasey Speakman wrote:
>
> 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.
