The way to address the problems with having to update too many references to which private storage I'm using is with a dictionary and identifiers:
https://gist.github.com/markhamburg/e3b9af785d06ed392e4498e569045b25 But it starts to feel like I'm re-inventing elm-parts/elm-mdl and a more realistic use case wouldn't be able to get away with everything just referencing model.value. Again, this particular use case is utterly contrived but I can easily see a date picker slotting in similarly — just with a lot more logic in the implementation. Mark On Sat, Sep 10, 2016 at 3:00 PM, Mark Hamburg <[email protected]> wrote: > 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.
