Fork me on GitHub

I’m having trouble wrapping my mind around a good solution for this, so I’m hoping the community can help me out. I’m trying to background schedule an expensive computation and when the computation completes I want to update a subscription. I’ve written this and it works, but it seems hacky and frankly ugly:

  (fn [_ _]
    (let [query (subscribe [:participants-search-query])
          prev-query (atom nil)
          rv (atom [])                                              ; default return value while bg computation is running
          run-again (r/atom nil)]                           ; just used to signal the bg computation is done
        (when (not= @prev-query @query)
            (.runAfterInteractions InteractionManager
                                   (fn []
                                     (reset! rv (lunr/search @query))
                                     (reset! prev-query @query)


@seantempesta: can you dispatch an event when your computation finishes to update a part of your app-db, and subscribe to that part of app-db?


@danielcompton: I could, but I was hoping to avoid doing that for temporary computations.


I suspect it may be simpler than the alternative simple_smile


@danielcompton: I’ve come around on this issue. Thanks for the good advice. simple_smile


Is there a conventional way for dealing with the following scenario: I dispatch an event A which updates the db, based on that updated model I want a second event B being dispatched.


When I dispatch event B from within the event handler of event A, the event handler of event B gets called too soon; not with the model as updated by event handler A


Correction: it does work that way. The problem was something else.


Still: would you implement that scenario the way I described?


@slotkenov: if B's effects can't be implemented during A's handler for some reason then i say go for it... i think i have a couple of cases like that in my app, but they are rare


@mccraigmccraig: well B’s effects could also be implemented in A’s handler. I had them separated because logically they seemed two different actions. But now that I think of it, it could make sense to put them together, simply because of the fact that B needs to happen when A happens.


@slotkenov: in many such cases i have pulled the app-db transformation out into a function called from both A and B handlers


@mccraigmccraig: That seems like a nice solution when separation might be needed, thanks!


@ndroock1's question at reminds me that I want to make a serious but small re-frame app as an example


Because it takes a bit of experimentation to figure out how all the pieces go together


(It'll probably be a clone, where people can submit sentences & translations.)


My question is, should I use the re-frame-template or should I just use three files (project.clj, index.html, and core.cljs—with maybe a core.clj if/when I talk about backend)