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.