One other note: If you don't care about Reactor and the Debugger but do care about async problems, you could get almost the same structure by passing back Model -> Model functions instead of Model values. Doing so may cause you to receive a visit from the Elm thought police but it is entirely semantically viable within Elm (and it's what I could imagine a lot of other functional languages doing by default).
Mark > On Aug 27, 2017, at 1:33 AM, Vlad GURDIGA <gurd...@gmail.com> wrote: > > 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, 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, 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. -- 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.
