re-frame

https://github.com/Day8/re-frame/blob/master/docs/README.md https://github.com/Day8/re-frame/blob/master/docs/External-Resources.md
benny 2021-01-09T18:18:12.216500Z

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-himik 2021-01-09T18:43:53.216600Z

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-himik 2021-01-09T18:45:04.216800Z

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.

benny 2021-01-09T19:17:34.217Z

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-himik 2021-01-09T20:12:09.217200Z

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