Fork me on GitHub
#re-frame
<
2016-05-11
>
seantempesta01:05:05

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:

(register-sub
  :participants-search-lunr
  (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
      (reaction
        (when (not= @prev-query @query)
            (.runAfterInteractions InteractionManager
                                   (fn []
                                     (reset! rv (lunr/search @query))
                                     (reset! prev-query @query)
                                     @run-again)))
          @rv))))

danielcompton02:05:14

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

seantempesta03:05:19

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

danielcompton04:05:12

I suspect it may be simpler than the alternative simple_smile

seantempesta08:05:36

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

slotkenov15:05:32

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.

slotkenov15:05:31

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

slotkenov15:05:01

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

slotkenov15:05:55

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

mccraigmccraig16:05:24

@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

slotkenov16:05:11

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

mccraigmccraig17:05:59

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

slotkenov17:05:44

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

fasiha19:05:49

@ndroock1's question at http://stackoverflow.com/q/37164091/500207 reminds me that I want to make a serious but small re-frame app as an example

fasiha19:05:26

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

fasiha19:05:54

(It'll probably be a http://tatoeba.org clone, where people can submit sentences & translations.)

fasiha19:05:01

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)