Personally, I think that "local state" or "accidental state" is a better name for this issue.
It is the state that has no business logic value. You can change it and nothing of consequence happens in the stuff that you do save in a database. It has everything to do with the interaction with the user. It supports that interaction in some way. Charlie was right, an accordion is a better example. You have a little bit of state that the developer doesn't have to handle. The developer could set some kind of shape of that state by using options or config of the accordion or it can just leave the accordion in its default state. The user can interact with the accordion and this could or could now be of importance to the developer. It can leave the events (open some section) just do the default behavior OR the developer could want to be informed when they happen in order to maybe log them from analysis purposes. It is very very easy to think about this accordion as being "a component". It is very very easy to think about using something different in it's place like a dumb component that's just a bunch of paragraphs. HOWEVER, the problem is not with the accordion as the implementation. That can be done easy. >From my view, the issue here is with how you scale a page when it is full of such "components". And here is the disconnect. If you focus on the specific accordion, you focus on how to create a pleasant API for the accordion (elm-sortable-table and autocomplete is an example of solving this kind of a problem) . If you focus on the general widget that the accordion is, you need to solve a completely different kind of API problem (elm-parts is such an attempt to solve this problem). Both of these focuses are valid but they solve different problems. I tried to ask for a solution to the second problem and I have been accused of steering the conversation away from the specifics and being disrespectful of everyone's time. I still think this is a very important problem and a very specific one. It is the kind of problem that might not have a solution without some kind of OO facilities because, from where I look it seams to be about "treating a bunch of stuff that are different types like the same thing". A GUI toolkit is the perfect example of a use-case for this problem. Just look at what GUI toolkits one has in functional language. Either they have bindings to GTK/QT (which are stateful) OR they have purely functional attempts that are used only by a minority (one has to wonder why is that ?). -- There is NO FATE, we are the creators. blog: http://damoc.ro/ -- 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.
