Hey Mark! 👋 Thank you for taking time to look into this! 🤓
On Thursday, August 24, 2017 at 7:18:44 PM UTC+3, Mark Hamburg wrote: > > 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. > I haven’t though of it in such a well-formalized manner, but yes, that sounds like it: I eliminate one level of indirection. Or at least at some level, because at the very top there is still a message that triggers the update, even if it’s a super-generic one. 🤔 > It is entirely based on data and hence should be compatible with message > recording for the debugger. > This looks about right too, as I mentioned in my response to Robin <https://groups.google.com/d/msg/elm-discuss/ta64y4JBMc4/kZK7DqQxCwAJ>, the debugger does as good of a job as it can with what I’m giving it. 👽 > 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.) > Yeah, that’s true. As I’ve mentioned <https://groups.google.com/d/msg/elm-discuss/ta64y4JBMc4/kZK7DqQxCwAJ>, the reason why I haven’t sensed this problem is because I’m not using the Elm Reactor, because I don’t know how to get ports playing inside 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. > Hm… I haven’t thought about this aspect of the commands+subscriptions duo, although I think I understand the mechanics. 🤔 So far I think I’m in luck: I have one port (a in/out couple actually) for talking to an external rich text editor, which I expect to be modal. The user clicks a button, the editor opens in a modal dialog, edit-edit-edit, then closes the editor and passes back to Elm, so it’s serialized which means there should not be any other changes to the Elm state while the editor is open. 😎 I’m guessing in time, there could come in more things like background sync-up of some kind, and then it’ll be really good to keep in mind these things that you’re mentioning about stale states. 🤓 Thank you! Really good catch! 👍 -- 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.
