Fork me on GitHub

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:


I’m sure you mean you are using Accountant for history, right? 😄


@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:

 (fn [db, [_ id]]
   (assoc-in db [:report-section :selected-report :id] id)))
Is it normal in re-frame?


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)
It add a level of abstraction which you may or may not like, but makes the event handler look more clean.


@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.

  (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 :-)):

  (path [:report-section :selected-report :id])
  (fn [_ [_ 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.