This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-12-27
Channels
- # adventofcode (1)
- # announcements (16)
- # babashka (16)
- # beginners (59)
- # calva (13)
- # clj-kondo (7)
- # clj-on-windows (3)
- # cljdoc (5)
- # clojure (85)
- # clojure-dev (5)
- # clojure-europe (4)
- # clojured (3)
- # clojurescript (87)
- # cursive (12)
- # emacs (4)
- # fulcro (15)
- # gratitude (1)
- # introduce-yourself (4)
- # malli (7)
- # off-topic (5)
- # polylith (6)
- # re-frame (15)
- # reagent (2)
- # shadow-cljs (5)
- # tools-deps (6)
- # web-security (2)
- # xtdb (5)
If I want the value of :db
in an effect handler (`reg-fx`), I need to pass it into the effect value of the event handler, right? so {:do-stuff [:interesting-stuff 42 db]}
instead of just {:do-stuff [:interesting-stuff 42]}
?
I could write an after interceptor to do this automatically
Hmm now that I think about it more, my need stems from not using subscriptions, so I will have to think on this further
I could deref app-db directly in the handler
re-frame.db/app-db
is not a public API.
What exactly do you plan to do with app-db in the effect handler?
I'm currently sending updates of all “lobbies” (this is a game server) to all connected players after certain player actions (such as creating a new lobby or leaving a lobby). In the client, this would be handled by subscriptions but server side, I have to do the querying and diff payload creation by hand
I'm not sure how this answers my question to be honest. My question is technical rather than domain-specific. So you might be e.g. getting a single key out of the db or maybe somehow doing something to the whole db. I'm now especially confused by the mention of a backend - do you use re-frame on a backend?
Yeah, I mentioned yesterday I'm experimenting with it as a server side workflow because I really like how it forces writing pure functions while allowing for injecting impure data and performing side effects. My particular use case is well suited because I'm only using It for web socket messages related to this part of the application: lobbies and active game state.
To your technical question, I'm relying on two keys from app-db, :lobbies and :users. At the moment, broadcasting updates is simple: any change sends the full list of lobbies to all connected users. I don’t worry about creating diffs or subsets in the interest of simple code, especially given that I know I won’t ever have more than 100 users at a time. (It’s an unpopular game lol)
Ah, right. I'm kinda all over the place here so don't recall all the specifics often. In that case, I would just pass those two values alone to the effect - lobbies and users. No need to pass the whole db.
No worries, I shouldn't assume everyone remembers all of my details lol. Thanks for the tip, I’ll give that a try!
Interesting! I'm bound to clojure for both emotional and code size reasons but I have been looking for a reason to check out elm