Fork me on GitHub

@hjrnunes: The way we handle routing in our application is by making a call to a function navigate that takes the route as a parameter. We first make a call to setToken on the History object and then find the handler that matches the route using Bidi. The handler contains the call to re-frame/dispatch. This pattern has worked well for us so far.


@lsnape: Thanks! That’s what I was doing. But I ended up going with the other way I described. It didn’t feel right to call set-token straight from the views. It seemed to me that navigation is an event. So I ended up creating a re-frame handler for :push-url-for that takes on the same parameters of bidi’s path-for and calls it. The handlers for the url dispatch then dispatch other re-frame events. It actually works really well with the advantage of consistent use of dispatch throughout the app. In fact it even made things more organized. Now I have (dispatch [:push-url-for :a-view :param param]) instead of, say, (handler-fn (dispatch [:select-item nil]) (dispatch [:active-pane some-pane]) which happen in the bidi route handler function.


Using a re-frame to dispatch navigation events to bidi ended up being a good way to group other related dispatches that need to happen, without having to create grouping handlers that only dispatch other handlers


guys does anyone have experience with debouncing loading states


what i mean is a loading view only shows if the request is taking longer than x seconds


I’ve noticed that the TODO re-frame app doesn’t use an ratom for it’s db. Is there a convention that I’m missing?


re-frame defines app-db for you


Ah I see, so with the initialize-db I’m just giving the whole database to re-frame as a plain map and I’m guessing every handler it’s doing a reset!?


something along those lines yes


but you don’t need to initialize db if it’s just a empty map


it’s used to replace the re-frame defined db with your own db which may have some initial values for your application


In the docs, the following is flagged as "not so good:"

(defn  todos-list
    (let [list-id (subscribe [:list-id])
          list    (subscribe [:todos-list @list-id])]
        (fn []
        ... render the list)))


It’s possible that the change of active-wolo triggers a re-creation of the details component. In that case the two subscriptions would be re-created as well, with the current value for active-wolo. It depends on how you „call“ the details component.


@joshuanjordan Your code captures the initial value of active-wolo and uses it as the argument for the 2nd :sub/wolo-details subscription. The problem is that any subsequent changes to active-wolo won't cause a change in the :sub/wolo-details subscription. So the :sub/wolo-details subscription will be for the first value of active-wolo and its will never change.


Which may be fine. If it isn't fine, then you'll have to get into dynamic subscriptions which are subtly different (subscribe [:sub/wolo-details] [active-wolo]). The handler you wirte is different too.