elm-mdl is loaded with private state support in order to support various Material Design Language elements. I'll let those who built it go into those details. I was responding to the argument that the elaborate apparatus that elm-mdl uses is "not the right way to do this in Elm" but those arguments haven't been accompanied by examples of how one should build support for MDL. Evan's sortable table provides a demonstration of storing data separately from the view state but requires little behavior from the table element and doesn't edit the table data. Other examples beyond MDL that people have raised include date pickers that need to store information about whether they are displayed, what month is displayed, etc and none of this has to do with the public/shared state that is the actual chosen date. Again, we haven't had a demonstration of how to handle this. Last I knew, for example, NoRedInk was bridging to a JavaScript component for date picking and meanwhile Evan has argued that greater reliance on existing JavaScript code is a bad thing because Elm is supposed to be better than JavaScript.
So, in that context, I tried to see what code patterns would support a UI element with both public and private state and that had element specific behavior without the special state store that elm-mdl built. What I linked to shows that while you do have to explicitly store the private state for the view somewhere, it doesn't seem overly onerous to do so nor to build or work with a UI element that has such a split between shared and private state. As for my Elm experience, I've built a moderately large project in Elm working with other developers. We've tried it the giant model way and the codebase became tricky to sustain multiple developers working at once and the ability to reason about it declined. Just relying on the type checker for refactoring was a lot like refactoring in C++ by changing a header file and fixing compiler errors until it built again which was arguably better than the experience in untyped languages but not in and of itself miraculous. We then did more to break the app into pieces and that worked but the plumbing often felt ugly, so the question has been whether there's a better way to decompose and structure large apps and what guidelines should be in place for structuring code when scaling up a team. Mark > On Sep 9, 2016, at 7:25 PM, Leroy Campbell <[email protected]> wrote: > > Mark, > > I don't understand why so much concern about private state. The reason > components (in JS frameworks) need private state is to protect them from > accidental mutation by callers. With immutable data, I don't see a need to > hide data. > > I've had to maintain several 10K+ JavaScript codebases. The number one > problem I've had is mutable state spread throughout those apps. Unit tests > don't help here; sure components work fine in isolation, but no amount of > disciple saves you from bugs where a reference is leaked from a nested data > structure then mutated in a closure somewhere else. > > Do you have a real case for components in the way you propose? To me, it > doesn't seem like you've tried to build anything substantial with Elm to > understand Evan and Richard's point of view on the matter. > > -- > 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.
