That's insightful, but let me poke at these statements anyways, and please correct me where I'm wrong... an exercise in learning:
<< - text input: local state works great until you start to add validation, then it is usually better to have it in global state. Also, clearing form fields on submission is easier to handle with global state. >> I don't save to global state the transient state of each component, only the state of the entire app at the time I'm transitioning the app's sate, e.g. submitting a query. That final state goes into global state. Local state for me, being new to React so forgive me if I'm doing it wrong, is a way for me to tell React to render my keystrokes. I don't need to store those keystrokes in global state until the user hits submit. Then I validate etc. << - loading indicators: local state works fine, until you start handling network errors and have to clear the loading indicator when there's an error. >> Right. I see what you mean, but the loading indicator's local state is accessible to me and can be reset when I detect a network error. In what situations would it be not accessible? (React question) << - collapsed/hidden flags: for drop down menus, nav drawers, etc. Again, it's easier to use global state so you can do things like close the menu when the user clicks away from it (a pet peeve of mine are menus that can only be closed by clicking on the menu itself - argh!). >> Oh again, this is pointing to an issue with accessing a component's local state from outside the component. Is this an issue in React? << I'm finding that most of these things become ridiculously easy with re-frame. Simple example - create a "menu-closing" handler middleware and attach it to any handlers where you want the menu to close. >> I've been reading up on re-frame and it's not a foreign concept to me but I need to think a lot more about the details or missing details. It sounds like it's got some powerful patterns bundled together. On Tue, Mar 17, 2015 at 7:09 PM, Mike Haney <[email protected]> wrote: > In my experience, using component local state seems harmless enough in the > beginning, but I almost always find a need to move it to global state as an > app matures. A few common examples: > > - text input: local state works great until you start to add validation, > then it is usually better to have it in global state. Also, clearing form > fields on submission is easier to handle with global state. > > - loading indicators: local state works fine, until you start handling > network errors and have to clear the loading indicator when there's an > error. > > - collapsed/hidden flags: for drop down menus, nav drawers, etc. Again, > it's easier to use global state so you can do things like close the menu > when the user clicks away from it (a pet peeve of mine are menus that can > only be closed by clicking on the menu itself - argh!). > > I'm finding that most of these things become ridiculously easy with > re-frame. Simple example - create a "menu-closing" handler middleware and > attach it to any handlers where you want the menu to close. > > -- > 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.
