Fork me on GitHub

@shyambalu perhaps a technique like this: (dispatch [:with-loading [:some :ajax :call]]) notice that the "real event" is given to :with-loading as a parameter.

   (fn [{db :db}  [_ real-event]]
       {:db   (assoc  db :loading?  true)
        :dispatch-n   [ (with-meta real-event {:flush-dom true})
                        [:take-down-loading]]}))               ;; takes away loading flag


Note: this does require v0.8.0 but, as @shaun-mahood says, the upgrade is pretty easy - just some renames - assuming you haven't written your own middleware, and even then not too bad.


No wait. Ignore the suggestion above. I was shooting from the hip. That :take-down-loading event is going to get processed before the ajax call has returned. (I have used this technique above but only when the "real event" is a CPU hog which locks up the thread and blocks the trailing {:take-down-loading] until the right time ... not an ajax call which will allow that take-down to happen too quickly.


@mikethompson yep similar to that is the way I was thinking of doing it in 0.8.0


hello folks - i wonder if dereferencing atoms in let blocks is a good idea? or should they be better dereferenced further down in the code?


in your latest todo mvc example, they all are dereferenced further down in the code. any reasons for that?


Your question isn't clear to me. Could you provide more details


@michael.heuberger deref them where ever it makes sense to do so


Well, if it is a Form-2 and you deref them outside the returned render fn, you may not get the result you expect.