This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-01-09
Channels
- # asami (10)
- # babashka (11)
- # beginners (24)
- # braveandtrue (1)
- # cider (4)
- # cljs-dev (4)
- # clojure (88)
- # clojure-europe (19)
- # clojurescript (6)
- # code-reviews (7)
- # conjure (2)
- # core-async (2)
- # css (3)
- # cursive (11)
- # expound (81)
- # fulcro (2)
- # hoplon (1)
- # off-topic (42)
- # pathom (1)
- # re-frame (5)
- # shadow-cljs (17)
- # spacemacs (25)
- # testing (6)
- # tools-deps (3)
- # xtdb (12)
how bad is it to use an atom for things like an access token for simpler access?
(defonce request-token (atom nil))
(re-frame/reg-event-db
:login-success
(fn [db [_ token]]
(reset! request-token token)
(assoc :logged-in true)))
vs
(re-frame/reg-event-db
:login-success
(fn [db [_ token]]
(-> db
(assoc :logged-in true)
(assoc :token true))))
(re-frame/reg-event-fx
:retrieve-messages
(fn [{token :token :as db} _]
:http {:oauth-token token...}))
Your event handler becomes impure - re-frame docs describe why that's bad.
At the very least, you can move reset!
into its own effect.
But how storing the token in app-db
is less convenient? Your example doesn't really show the issue - :retrieve-messages
is only there once, and its handler is broken.
If you store the token in a separate atom, you will still have to get it from that atom - I don't see any significant differences from just using app-db
. But if you want to keep your event handlers pure, you will have to use effects and co-effects, which make using an extra atom clunky.
I guess that’s especially true in this example. the actual location of my token is buried under a parent key, but it’s still not much of a difference, but my concern is especially the sanity of my db
but i can fix that other ways
(let [token (-> db :auth :token)]
(api-call token))
vs
(api-call (:auth-token @app-state))