Not to go too far down the 'communicate with local state' tangent, but isn't a global event-bus (eg. a (chan)) sufficient? I use om and app-state for all state (except projections) and haven't found any of the given scenarios a challenge.
For anyone deciding about whether to jump on board BTW; the two Mikes are awesome and give this a _lot_ of credibility. If this had been around last year I think I would have bitten your hand off Mike ;). Don't get me wrong, David and Om are fantastic, but most of the 'how do I do this' community in Om or React has been from a small number of people, including Mike. This really feels like a solid, well engineered library which allows me to build solid, well engineered applications being opinionated enough so I don't go off track but flexible enough not to lock me in. And the fact MikeT has done a non-trivial app means a lot to me. Great work, and keep up the excellent community. (that's enough sycophantic nonsense from me). On 18 March 2015 at 07:02, <[email protected]> wrote: > On Wednesday, March 18, 2015 at 3:09:12 AM UTC+1, Mike Haney 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. > > We solve all of these problems by having components subscribe to global > events and using React mixins (with om-tools). This way global state is not > polluted with all of the minutiae. > > For example, we implement the loading indicators by mixing in the "loadable" > mixin and handling the whatever actions trigger the updates/loading. This way > when an async action gets initiated, the component gets an "[:initiated > :action]" event and e.g. draws an overlay with a spinner over itself. When > the action completes, the component handles a "[:completed :action]" event > with a success/error payload. This way the handling of error/success > conditions only useful to the component in question stays with the component > and reusable pieces get abstracted away. > > I'd say our approach is isomorphic to re-frame in this regard. > > -- > 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.
