I reworked my example in terms of passing back new counter values via messages (to be more like the auto-complete example):
https://gist.github.com/markhamburg/48f92aaccc419c4b2a93977d09afa4d7 Given the errors that I hit while writing it (and probably the earlier versions as well), the biggest problem when it comes to scaling is that this is the sort of thing where copy-paste-modify development is really natural — I have a new view to add, copy-paste-modify the code from a previous view. The problem is that on any of those modifications, I need to make sure I hit everything. Otherwise, it's really easy to end up linked to the wrong private state and to the extent that one uses the same type of view more than once, the type system won't catch this. Mark On Sat, Sep 10, 2016 at 12:43 PM, Mark Hamburg <[email protected]> wrote: > On Sep 10, 2016, at 8:52 AM, Oliver Searle-Barnes <[email protected]> > wrote: > > Mark, have you considered the approach that Evan took with > elm-autocomplete > <https://github.com/thebritican/elm-autocomplete/blob/master/src/Autocomplete/Autocomplete.elm#L164>? > Personally, I found this a satisfactory approach to the problem of private > state/events, I'd be interested to hear your take on it. > > > I watched the video when it came out but I hadn't looked closely at the > code at the time. I just did so and I had a variety of reactions: > > * There is a similarity between what I did and the auto complete code in > that the level above stores both the public state and the private state and > provides both to the view and update functions. > > * The autocomplete code places a lot of burden on the client. For example, > key code identification. This may be needed for configurability but I could > see it being a problem for consistency across multiple auto completes in a > larger project. It could probably benefit from a standard usage path or an > example of how to build such a standard usage path as part of the examples. > > * The communication mechanism back from auto complete is interesting in > that it returns messages or rather maybe messages. This is the sort of > pattern that deserves more attention. For example, should a fully > generalized update function look something like the following? > > update : > Config parentMsg > -> StateFromParent > -> LocalMsg > -> LocalState > -> (LocalState, Cmd LocalMsg, Maybe parentMsg) > > (Actually, autocomplete splits up the state from the parent into how many > to show and the items to show and spreads them out in the update > parameters. I don't recall a part of the API design discussion that went > into why this particular parameter order. I picked the order I did here in > order to make the function look more like a classic TEA update function > with extra parameters at the beginning.) > > * One thing that will be different between the approach I took and this > approach is that if any of the local state depends on the global state — > e.g., in a date picker, externally setting the date might change the month > displayed — then the autocomplete approach which would use a message to set > the date at the parent level might have an awkward sequencing problem in > that we would do something like the following: > > update the date picker in its update function > process the update the date message > update the date picker again because the date changed > > Basically, routing things back through the update function as a message > can interfere with de-bouncing. In contrast, I specifically stored the > update to the local state after updating the public state in my counters > example. One could do this as well in the deliver messages back approach, > but the natural place to handle messages feels like at the end of the > update function in essentially a tail recursive call. That said, using > messages is definitely a more versatile approach. > > Mark > -- 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.
