I'm curious about how people are handling routing in re-frame apps. Secretary seems fine for route matching, but I'm (perhaps out of ignorance) a bit dubious about accountant- seems like just a bit too much magic for my tastes at first glance. I've done a fair bit of react/redux with the react-router for redux, and while I think it has some issues (especially around asynchronicity) it does do some magic that I kind of like. Is this a case where people wind up rolling their own with re-frame, or am I missing a library?

I should add that I've been in npm-land long enough now that I've really started to lose my roll-my-own instincts.

I'm using bidi for routing and accountant for history. Here's the example: https://github.com/PEZ/reagent-bidi-accountant-example

@willier Thanks, that answers my question, and gives me a starting point.

I'm inclined to think, based on my experience writing SPAs in Angular and React/Redux, that having an easy default way of handling routing is crucial.

Hey, folks. How do you manage app-db with 3+ depth? My handlers looks like that:

(reg-event-db
 :select-report
 (fn [db, [_ id]]
   (assoc-in db [:report-section :selected-report :id] id)))

I have it on some maps. But I also have seperate method for some large maps. You could a function set-id and then use it to be something like

(set-id db id)

@gklijs thanks, came to same idea.

was using setters for such updates, but had to ask community to be sure.

Oh, re-frame has path middleware for handlers. Cool.

(reg-event-db
  :select-report
  (path [:report-section :selected-report])
  (fn [report]
    (assoc report :id id)))

@armed you can even do this (although I'm not sure it is clearer :-)):

(reg-event-db
  :select-report
  (path [:report-section :selected-report :id])
  (fn [_ [_ id]]
    id))

@mikethompson yes, but that scares me :)

Too cryptic imo

What are people's thoughts on whether it's preferable to pass data down to subcomponents as properties vs having the subcomponents subscribe to the appropriate sub-tree of the app-db?

@timgilbert: My general approach - if the component makes no sense outside of the subscription context, or there are other substantial benefits to subscribing, then I subscribe directly If the component could be reused elsewhere in the app, or there are other benefits to passing things in directly, then I pass in props. Usually I go back and forth a few times between the 2 as I'm iterating on part that I'm not sure of, and it's usually a pretty simple change if I haven't gone too crazy.