This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-08-05
Channels
- # architecture (23)
- # bangalore-clj (2)
- # beginners (93)
- # cider (27)
- # cljsjs (2)
- # clojure (66)
- # clojure-russia (9)
- # clojure-spec (28)
- # clojure-uk (3)
- # clojurescript (47)
- # cursive (2)
- # data-science (2)
- # datomic (10)
- # editors (9)
- # emacs (4)
- # figwheel (3)
- # figwheel-main (1)
- # hyperfiddle (2)
- # jobs (1)
- # nrepl (59)
- # off-topic (2)
- # onyx (10)
- # pedestal (1)
- # re-frame (13)
- # reagent (9)
- # reitit (17)
- # shadow-cljs (8)
- # tools-deps (4)
- # vim (2)
hi, quick question that i can’t seem to find in the docs - can i subscribe to an event in different places? for example, :login-success
i’d like to react to with different things - maybe create a websocket, etc. (currently, I want to react to that with a couple different statecharts). is there another style i should be looking at for this? Or am i thinking about it incorrectly? Thanks much for any advice!
like, in regular JS, i can latch a couple different things onto a promise, and when it succeeds, a couple functions are called - looking for something along those lines
You can subscribe to the same information in the database multiple times. You don't subscribe to an event. An event gets run and it may set some info in the database, but you don't subscribe to the event directly.
right, so i can use a subscription … just about anywhere? Can i create some random function that subscribes to something, and is run when it changes?
I'm going to tentatively say yes to that. I don't fully understand how it all works and what exactly gets run when, however....
(reg-sub app-initialized [db]
(get-in [:some :path] db))
(defn random-func []
(let [is-init? (rf/subscribe app-initialized)]
(when (@is-init?) (do-something)))
still not right, but ya knowuh…except the second part there is actually correct, and subscribing to that thing right
I have a similar situation where I call out to an api using http-fx. The call takes a map including an :on-success which expects an event. Many of these need to trigger multiple events in my app, so I define an event for it which basically just fires off 2 or 3 other events using dispath-n
yeah, that might be more “obvious” - instead of things listening for the one event (that might be hard to trace), i’m explicitly dispatching a set?
Thats what I do. I have a call to an api that pulls a load of info from a database so it can take a few seconds. When it comes back I need to alter the ui in a few places and do a couple of other things. One event dispatching multiple others is fine and probably less error prone than having lots of things watching seperately