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))
If you consider something a part of your app's state, then store it in app-db
. I cannot really add anything else.