As a thing of the below example, it would be really really awesome if I
could 'subscribe' to the connections instead of needing to actively request
them, as in just have the subscriptions be something like this for the
below example:
```elm
subscriptions model =
Sub.batch
[ if model.uid <=0 then Sub.none else RoomConnection 0 connectionMessageMapper
, if model.uid <=0 then Sub.none else RoomConnection model.uid
connectionMessageMapper
, etc...
]
```
Or perhaps:
```elm
subscriptions model =
Sub.batch
[ RoomConnection 0 connectionMessageMapper `Sub.when` model.uid >0
, RoomConnection model.uid connectionMessageMapper `Sub.when` model.uid >0
, etc...
]
```
Such a way to register such things would remove my need of many commands,
though not all for sure.
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.
