Here is a new gist that encapsulates the update logic for these public/private pairs into a shared function,
https://gist.github.com/markhamburg/b4613175fd65f6d25a58e3f9c0044a09 Mark P.S. This does point to the desirability of having .field= or some other notation as a way to create the setter function: \x m -> { m | field = x } And if I were in a language like Lua or JavaScript, I would probably create a function to take a field name and give me back a getter/setter pair. On Fri, Sep 9, 2016 at 2:02 PM, Mark Hamburg <[email protected]> wrote: > The most general/worst case has some per view private state information > for every view and that state has to be managed in the model. Every view in > that case also needs routing for its messages so that the update can link > back up with that private state. If that is the case, then question is how > painful is it in practice to code to? To what extent does it need to be > buried away by utilities? Probably the biggest argument for it being a > problem is that to add a new view has to touch a lot of places. For > example, to add another counter-with-stack to my example, we need to add a > new private state to the model, initialization code for this new private > state, update code for this new private state if it depends on the public > state, a new message to route messages to this new counter public/private > state pair, and code to include it in the view. This last one would have to > happen no matter what. The only real ugliness is that the update logic gets > repetitive, though I could imagine doing something that would use setters > and getters to standardize the access and consolidate the logic. > > Mark > > On Sep 9, 2016, at 1:40 PM, OvermindDL1 <[email protected]> wrote: > > That style does seem to be the usual of how it starts. But let's say you > wanted this counter all over the app, there is a counter in some tab, a > list of messages each has a counter, all the counters are entirely visual > and the numbers do not mean anything anywhere, now how would you store them > all? My immediate thought would be, say, an array or dict, I'll use a Dict > for example. Let's key it on something, so a string or int, then we have > to 'key' each of the views with this key value, which it then attaches to > its own messages to know which is doing what. However you notice you have > to keep some state through the views so that you do not re-use the same > key, whether integers or strings or anything, say you want to render the > same list view in two different places, each list has a large list of > counters, they both need unique ID's. You could pass in an integer or > string to each and internally it could add/concat those to internal values > to distinguish, or to make it easy just make your key a list of > ints/strings, then as you get 'deeper' in the view tree you just add > another key to the list with a unique id that only needs to be unique to > the local function and nothing else. And now it is realized that > elm-mdl/elm-part's method was just re-made, this is exactly how `elm-part` > works. > > It gets even more interesting if you have an identical thing, say, a > table, with identical data, but 'shown' in different ways different > orderings, filters, etc..., each of which is user customizable but the > program does not care how the user views it, same issue. > > Or down to a ripple button again, it needs to hold a little bit of > internal state to know how many ripples to have at this second and how much > longer each lives. It would be scattered all over the view, buttons > everywhere in tabs and div containers and more, each needs a unique 'key' > again, back to the elm-part method if you want an easy way to keep them > unique, either that or scatter your model with hundreds/thousands of little > button containers or do the book-keeping yourself with a dict of it that > you index into as needed. > > There just does not seem to be a way to make such reusable views that need > to do stuff that the program does not care about. WebGL has nothing to do > with this (and I still have no clue why it was brought up in the old > thread, certainly would not let ripples work on IE9, which I have to care > about). It is just a simple aspect of some views have public data (which > should be fed to it by the user) and some private data (which is for > internal bookkeeping purposes only, like view states, a ripple or an > accordion or so forth) and how to manage them in a useful way. > > > On Friday, September 9, 2016 at 2:01:50 PM UTC-6, Mark Hamburg wrote: >> >> Over on Elm dev, there's been a debate over how to handle private state >> for views that also have public state. Evan's sortable table and his recent >> updates to the guide with respect to reuse have emphasized how to avoid >> building much state into a model but that's left a gap for the cases where >> private state does matter. A real example would deal with things like date >> pickers or ripples, but implementing those would involve lots of code that >> had nothing to do with how one handled private state and simply had to do >> with calendars or ripples. So, I took the counter example from the guide >> which was used to show how to do models (for similar reasons of limiting >> distractions) but would really fit better in the view only approach now >> being advocated and added some private state. Specifically, I introduced >> counters with a stack of values. The code in this gist actually provides >> two views onto a shared counter value with each view having its own stack: >> >> https://gist.github.com/markhamburg/dd2b5b1d30db1f03ccee055a4e070677 >> >> This implementation isn't quite as minimal as it could be. In particular, >> I included the notion of updating private state when the public/shared >> state changes but I don't actually use it. On the other hand, for an >> example, I wanted to see where it would fit in. In practice, I wouldn't >> include it if it wasn't needed but I would probably still bottleneck the >> update to the shared state so that it could be added later if necessary >> without having to hunt down all of the places where the shared state is >> changed. >> >> 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. > > -- 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.
