On Tuesday, March 17, 2015 at 4:27:30 PM UTC+1, marc fawzi wrote: > << > 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
Yes, that's the main reason. Also things like `loading?/updating?` states to represent the progress of async actions and other similar cases. > > > << > 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 That's also possible. We keep that data in the `:reference` part of the app atom. In our case it's mostly used for common lists of values, so nothing spectacular. > > > > > > > > > > > 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.
