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.
