In this case it is just filling in for 'something' that can dispatch some
messages to `update` and dispatch commands to `command`. I'm not sure how
to dispatch those without some dispatcher that is already acting like the
existing update...
On Thursday, August 11, 2016 at 1:21:42 PM UTC-6, Kasey Speakman wrote:
>
> I'm not sure I like it either. Seems like a lot of UI commands would just
> be auto-converted to events by `command`.
>
> However, in your example, I'm not sure what your filter code is about (my
> ignorance). If I am understanding it right, it's filling in for the case
> when you need to respond to an event and issue another command. This also
> seems like a separate concern from what I mentioned.
>
> On Thursday, August 11, 2016 at 1:53:15 PM UTC-5, OvermindDL1 wrote:
>>
>> Yeah I was playing with the idea for more message types though still not
>> convinced yet. Let's go hog-wild for a second to see how it would look
>> with a fairly major overhaul and multiple message types though:
>> ```elm
>>
>> {-| Msg is used for global message dispatching, handled only by the
>> `filters` callback -}type Msg
>> = ConnectTo Int
>> | RoomConnected Int
>> | ReceivedMessage String
>> | MsgOnInput String
>> | SendMsgDo
>> type CmdMsg
>> = FocusInputBox
>> | ScrollInputBox
>> | ConnectToRoom Int
>> | SendMsgToRoom String
>> type UpdMsg
>> = JoinedRoom
>> | MsgTyped String
>> | MsgSent
>> type alias Model =
>> { uid : Int
>> , msg : String
>> , msgs : List String
>> }
>> init : ( Model, Cmd Msg )init = ( Model 0 "" [], connectToServer )
>> filters : Msg -> Model -> States Model Msgfilters msg model =
>> case msg of
>> ConnectTo rid -> States.enableAll |> States.sendCommand (ConnectToRoom
>> rid)
>> RoomConnected uid ->
>> States.enableAll
>> |> States.sendCommand FocusInputBox
>> |> States.sendCommand ScrollInputBox
>> |> States.sendUpdate JoinedRoom
>> ReceivedMessage msg -> States.enableAll
>> MsgOnInput msg -> States.enableAll |> States.sendUpdate (MsgTyped msg)
>> SendMsgDo -> States.enableAll |> States.sendCommand (SendMsgToRoom
>> model.msg)
>> update : UpdMsg -> Model -> Modelupdate msg model =
>> case msg of
>> JoinedRoom -> { model | msg="", msgs=[] }
>> MsgTyped msg -> { model | msg=msg }
>> MsgSent ->{ model | msg="" }
>> command : Msg -> Model -> Cmd Msgcommand msg model =
>> case msg of
>> FocusInputBox -> focusMessageInput
>> ScrollInputBox -> scrollScrollable Helpers Scrollable_Bottom
>> ".messenger-mesglist"
>> ConnectToRoom rid -> connectToRoom rid
>> SendMsgToRoom msg -> sendMsgToConnectedRoom msg
>>
>> ```
>>
>> Eh I am not sure I like it, at all actually. It basically converts the
>> usual helper functions into in-line in the case branches. It separates the
>> commands and update messages out, however all the original logic is now in
>> filter, which is basically just redistributing things (maybe it should be
>> called `router` at this point) and is growing larger then its purpose was
>> meant. Not sure of a good API yet...
>>
>>
>> On Thursday, August 11, 2016 at 12:32:44 PM UTC-6, Kasey Speakman wrote:
>>>
>>> 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.
