<< The main difference with re-frame is that we allow components to subscribe to events in order to manage their local state as we don't keep everything in the app state. >>
That's very cool if what you mean is storing state that no other part of the app needs to know about, like the keys being entered into an input field etc << There is some reference data common to every module which is the only part accessed by everyone (using the Om ref-cursors). >> Can you give examples? Let's say I have two components that use the same derived or raw data, I would put that data outside of app state, into a data store/cache/indexeddb/etc On Tue, Mar 17, 2015 at 7:14 AM, <[email protected]> wrote: > On Monday, March 16, 2015 at 8:53:59 PM UTC+1, Michael Campagnaro wrote: > > First off, re-frame looks really great, Mike. Thanks for writing it. > > > > My team has been working on a Reagent SPA for half a year and it's our > first CLJS project so we are feeling some pain due to design choices that > were not the best. We really like the re-frame pattern and want to > transition over to it. I'm attempting to work out a plan for this. Either > creating a new app on the side and porting code over to use re-frame or > gutting the current app in place. > > > > Since re-frame is so new it's hard to tell what the limitations are. On > one hand the codebase is small, simple and nothing stands out as being a > potential problem in a large app. On the other hand I can't help but be > skeptical and curious :) > > > > So I'd love to hear about anyone's experience using re-frame to power a > non-trivial app, preferably in production. Are there things that I should > be mindful of when scaling the re-frame pattern? > > We've been using a very similar approach to re-frame in production for > almost a year now (with Om instead of Reagent). The app isn't huge, but > it's a couple thousand lines of cljs. The main difference with re-frame is > that we allow components to subscribe to events in order to manage their > local state as we don't keep everything in the app state. > > The app is split into a namespace group for each module of functionality, > with each group having its own handlers for application events, remote > endpoints and components. > > There is one state atom for the whole application, although every module > gets it's own state under a separate key in the state map. There is some > reference data common to every module which is the only part accessed by > everyone (using the Om ref-cursors). > > I feel that the re-frame architecture scales very well if you are > consistent in naming and separating the responsibilities. > > -- > 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.
