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.
