Fork me on GitHub
#re-frame
<
2021-01-09
>
benny18:01: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...}))

p-himik18:01:53

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.

p-himik18:01:04

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.

benny19:01:34

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))

p-himik20:01:09

If you consider something a part of your app's state, then store it in app-db. I cannot really add anything else.