Here's where I find local state useful and I am curious how advocates of centralized state handle it:
A view component that allows editing. For example, click on the text and it changes to an input element. To me that is local state: "I'm in reading mode. Now I'm in editing mode." In my own app, I don't allow other components to change to editing mode when any other is in editing mode. This is a global state. So there is coordination, but it's not terrible as the component sets its local state and dispatches the handler for the app state at the same time. How do you all do it? Jamie On May 15, 2015, at 1:08 AM, Mike Thompson <[email protected]> wrote: > On Friday, May 15, 2015 at 10:27:46 AM UTC+10, Daniel Kersten wrote: >> Personally I find that moving state out of components as re-frame's >> subscriptions and handlers encourage is a desirable trait and would be >> cautious about reintroducing local state. >> >> Keeping my data in one place (and handling updates and queries through a >> centralised place) has made it a lot easier for me to manage complex data >> and logic. >> >> I've played with javelin in the past and it's a fantastic library. I quite >> like the idea of using it as a replacement for (or perhaps together with?) >> re-frames subscriptions (so reagents ratoms, really), but in my opinion >> reliance on local state is a mistake. > > > I'd like to violently agree with you. :-) > > State in the one place simplifies so much. The moment you have state in > multiple places, and that state needs synchronization, you have a problem. > > The strategy for solving that problem will involve either (1) things watching > other things for changes or (2) things telling other things they have > changed. The OO paradigm encourages a lot of distributed, synchronized > state, and the "The Observer pattern" is used to handle it. > > Those that use component local state with OM, have the same issues as the OO > paradigm. Sometimes they use a global bus to achieve synconization (things > telling other things that something has changed) which is a similar pattern > to various OO framemworks, like PureMVC. > > In the functional programming space, the movement seems to be towards FRP. > Data flows into functions and out again, in something of a pipeline. The > structure of those flows is more declarative WRT time. > > The thing is this: synchronization of state is a pain. Have as little of it > going on as you can. Putting all your data in the one place certainly saves > you from a certain class of problem -- reintroducing distributed state WILL > cause you some grief. I'm not saying "never do it", but I am saying "there'd > want to be a big payoff to warrant the pain". > > -- > Mike > > -- > Note that posts from new members are moderated - please be patient with your > first post. > --- > You received this message because you are subscribed to the Google Groups > "ClojureScript" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/clojurescript.
