This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-07-12
Channels
- # announcements (2)
- # beginners (36)
- # boot (6)
- # calva (2)
- # cider (18)
- # clj-kondo (1)
- # cljdoc (2)
- # cljs-dev (2)
- # clojure (130)
- # clojure-boston (1)
- # clojure-brasil (3)
- # clojure-czech (1)
- # clojure-europe (11)
- # clojure-italy (4)
- # clojure-losangeles (37)
- # clojure-nl (9)
- # clojure-seattle (2)
- # clojure-sweden (8)
- # clojure-uk (23)
- # clojurescript (13)
- # core-async (21)
- # cursive (13)
- # data-science (6)
- # datomic (12)
- # emacs (36)
- # figwheel-main (9)
- # fulcro (76)
- # juxt (2)
- # keechma (18)
- # leiningen (4)
- # off-topic (13)
- # pedestal (37)
- # re-frame (21)
- # reitit (2)
- # shadow-cljs (78)
- # spacemacs (23)
- # sql (13)
- # tools-deps (25)
- # uncomplicate (4)
- # unrepl (1)
- # vim (27)
@mihaelkonjevic When i do this, am i correct in assuming that on each app-db change, there are two blackboard reactions working? what i'm trying to do here is to have the blackboard computation (quick in this example, but might be heavier) only being performed once
AFAIK it should use same reaction, that's on the reagent core
My understanding comes from https://github.com/Day8/re-frame/blob/master/docs/SubscriptionFlow.md
i'll read this again (has been years) ... mhh i have a time value in this database i can log it in the reaction and see the result
in that page you linked, they use def'ed vars so there is only one instance of each reaction, gonna have to make some cache to make it work the way i want
that does the trick ! I can't see a production app restarting the keechma app so many times that the memory loss gets in the way
Hm, reactions are cached on the keechma level but using them directly is out of keechma's scope. I wonder if there's a simple way to optimize it