That is the same path I keep taking in my re-usable parts, always end up re-inventing something like elm-parts, and I've still yet to use elm-parts myself because things 'grew' into that design instead of thinking about them being reusable initially. Next time I'm going to use elm-parts from the front (which might be today, a new page SPA was just created in the morning meeting) for any pieces that need to be in more than 5 places at once with visual-only state and maybe business state.
And yeah, the copy/paste issue needing to remember to update the parts within it is 'mostly' solved by passing a tree of ID (a list of integers is what I use) and just appending to it on every call down. On Saturday, September 10, 2016 at 4:25:48 PM UTC-6, Mark Hamburg wrote: > > 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] > <javascript:>> 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] >> <javascript:>> wrote: >> >>> On Sep 10, 2016, at 8:52 AM, Oliver Searle-Barnes <[email protected] >>> <javascript:>> 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.
