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.
