Ignoring the commands and subscriptions part, I think this could be summarized
as being built around having any of the things that would send a message
instead send a new state. This eliminates the level of indirection of wrapping
the desire to change the state into a message and then unwrapping the message
to actually do the state change. It is entirely based on data and hence should
be compatible with message recording for the debugger. On the other hand, the
messages will lack semantic information. (One could work around that by adding
a logging text field that was set when building the update message but ignored
when applying it.)
Where this would seem to fall down is commands and subscriptions. Those are
going to produce asynchronous results and would risk baking in a stale model
state. This is particularly true for commands. Imagine, for example, wiring up
a tick command that will increment a tick field in the model after five
seconds. Since the command will be constructed to send the single "set the
state" message and since the only model it will have access to is the one that
existed when the command was constructed, it basically becomes a "reset the
state to where it was five seconds ago" command. If subscriptions really do get
rebuilt after every cycle of the update loop, then this isn't a problem for
them but the closure construction for each subscription is an expense. If they
don't get rebuilt — and the code in the initial posting suggests that instead
we're caching a subscriptions value — then as with commands, it would seem easy
to end up with code that resurrects stale states.
Mark
> On Aug 24, 2017, at 8:57 AM, 'Rupert Smith' via Elm Discuss
> <elm-discuss@googlegroups.com> wrote:
>
>> On Thursday, August 24, 2017 at 8:47:24 AM UTC+1, Peter Damoc wrote:
>> Without using Cmds and/or Subs it is an interesting approach if you use it
>> for managing very small bits of state (the open/close status of a dropdown)
>> but I'm afraid that it might bring performance problems if you use it for
>> the entirety of the app.
>> You basically have to computer all the possible future states of the app.
>
> Not so sure about that, as the callbacks seem to only be invoked in
> continuations?:
>
> Temei.view data.temei (\v -> c { data | temei = v })
>
>
>
> --
> 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 elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
