On Friday, March 13, 2015 at 1:31:01 PM UTC+11, Mike Thompson wrote: > On Friday, March 13, 2015 at 6:04:21 AM UTC+11, Jamie Orchard-Hays wrote: > > As I'm starting to explore re-frame in a playground app, one of my first > > questions is "how does one namespace handlers in a medium to large app?" > > I'm thinking you'd just simple namespace the keyname: > > > > (register-handler > > :foo/update-name > > ....) > > > > Is this your approach Mike, or do you handle it differently? > > Let's say you have N "panels" which you'd like to treat as "separate" for > some reason. These "panels" might be different "tabs", "dialogs", popups, > etc. > > Under src/panels, we create a folder for each panel, and in each such folder > we have the files: handlers.cljs, subs.cljs, db.cljs, view.cljs. All with > fairly obvious contents (see todoMVC). > > For us, db.cljs always contains a Prismatic Schema for the data associated > with that panel, plus there's a def called `db-root` which is effectively the > path within `app-db` for this panel's data. > > So all the registrations in handlers.cljs have "path" middleware pointing > them to `db-root` > > Back to answering your question ... when it comes to handlers we tried three > approaches: > > (register-handler > [:panel-id :event-id] ;; the event id can be more than just a keyword > some-handler-fn) > > > (register-handler > :panel-id-event-id ;; some sort of mash up keyword > some-handler-fn) > > > (register-handler > :panel-name/some-id ;; namespaced keyword > some-handler-fn) > > > They all work, I favour the last one, which just so happens to match your > suggestion. > > If ever there is a clash on id (you try to register two handlers for the same > id) you get warnings in the console. (It is allowed because we want figwheel > reloads to work). > > So this has been a long way of saying "yes, I agree".
Hmm. I should clarify - you normally don't have to use that db-root approach for different panels ... generally all your panels will cooperatively be working on what's in app-db. I shouldn't have even mentioned it. We use the root-db approach if we have to create panels which need to be their own "little world" - almost like a little mini-app within the main app - a modal dialog for a specific sub-purpose or, in my case right now, wizard-like steps which are given an input state, and produce output state (like a little mini app in their own right). Uggh. Too complex to explain. Anyway, ignore that I even mentioned the db-root strategy. Not needed for most cases. -- mike -- 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.
