Hi Mike - thanks for the notes and references. I have already devoured the wiki a few times, but the missing piece was how to validate the 'page' schema in the more focused handlers. That missing piece is, as you say, a page specific middleware. Quite obvious now you say it but it hadn't 'clicked' :).
Thanks. On 26 March 2015 at 11:53, Mike Thompson <[email protected]> wrote: > On Thursday, March 26, 2015 at 8:19:28 PM UTC+11, Colin Yates wrote: >> First - loving re-frame, mainly because it names the abstractions I found >> myself fudging around with when using om (which is also great). >> >> Anyway, in om I attached a watcher to the root app-db which validated >> against a global schema, and whilst it stopped invalid data getting *into* >> the atom (as opposed to the 'after' middleware) it sucked at reporting >> errors. I am not clear on the best approach using re-frame. >> >> My app is non-trivial and has a number of discrete logical 'pages', none of >> which care about the others, so it makes sense to do something like: >> >> {:page-a {...} >> :page-b {...}} >> >> In a given page there might be quite a deep tree as well, and each handler >> tends to be quite focused (using (path ...)) on a sub-tree. >> >> I could: >> - continue with the watcher on the ratom >> - have a macro which defines a handler with just its schema (which would be >> _very_ noisy) >> - attach the validation at the 'page' level >> >> My preference is by far at the 'page' level, but I am struggling to see the >> plumbing. I would be happy if each handler validated the 'page' structure, >> but because the handlers typically use the path they don't have access to >> the higher level page. >> >> In addition, I can't assume data-symmetry between the db and the schema >> (e.g. I can't simply take the 'path' provided to (path..) and (s/validate >> (get-in big-schema 'path')) as the schema uses predicate functions (s/both >> etc.). >> >> I hope that is clear - any suggestions? >> >> Thanks! > > First, if you haven't seen it already, I'll recommend reading this: > https://github.com/Day8/re-frame/wiki/Debugging-Event-Handlers > > So, don't do schema checks via a watcher -- the re-frame way is to use > middleware. > > Next, if you have largely independent "pages", treat them as almost > independent sibling apps. Each page has its own source sub-directory > containing associated handlers.cljs, subs.cljs, views.cljs and, importantly > for this discussion, its own db.cljs schema. > > Each page gets its own "branch" of "app-db". And in each page's db.cljs > there should be a schema for that branch. > > All the handlers for one page should use "path" middleware to "focus" the > page's handlers to that page's branch of "app-db". Equally, each handler for > that page should have middleware which checks that page's schema after each > handler has run. (This does mean your schema-checking middleware has to be > put to the LEFT of the path middleware > https://github.com/Day8/re-frame/wiki/Using-Handler-Middleware#6-ordering) > > Does that make sense? I can further clarify if necessary. > > -- > 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. -- 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.
