This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-05-11
Channels
- # admin-announcements (10)
- # arachne (2)
- # beginners (74)
- # boot (302)
- # cider (49)
- # cljs-dev (11)
- # cljs-edn (7)
- # cljsjs (13)
- # cljsrn (1)
- # clojure (164)
- # clojure-austin (1)
- # clojure-brasil (3)
- # clojure-finland (2)
- # clojure-greece (4)
- # clojure-russia (48)
- # clojure-uk (11)
- # clojurescript (138)
- # community-development (1)
- # cursive (13)
- # datascript (1)
- # datomic (19)
- # emacs (4)
- # events (1)
- # garden (1)
- # hoplon (123)
- # jobs-discuss (9)
- # keechma (5)
- # lein-figwheel (4)
- # leiningen (2)
- # luminus (15)
- # mount (1)
- # off-topic (8)
- # om (66)
- # on (1)
- # onyx (28)
- # other-languages (2)
- # planck (1)
- # proton (5)
- # re-frame (18)
- # reagent (15)
- # untangled (15)
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))))
@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?
@seantempesta: https://github.com/Day8/re-frame/wiki/Solve-the-CPU-hog-problem may help
@danielcompton: I could, but I was hoping to avoid doing that for temporary computations.
I suspect it may be simpler than the alternative
@danielcompton: I’ve come around on this issue. Thanks for the good advice.
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
@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 http://stackoverflow.com/q/37164091/500207 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 http://tatoeba.org clone, where people can submit sentences & translations.)