This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-06-01
Channels
- # announcements (2)
- # babashka (10)
- # beginners (133)
- # calva (28)
- # cestmeetup (1)
- # chlorine-clover (31)
- # cider (21)
- # clj-kondo (29)
- # cljs-dev (252)
- # clojure (60)
- # clojure-europe (24)
- # clojure-nl (3)
- # clojure-spec (13)
- # clojure-uk (17)
- # clojurescript (47)
- # conjure (20)
- # datascript (2)
- # datomic (4)
- # figwheel-main (4)
- # fulcro (71)
- # helix (16)
- # jobs (1)
- # meander (56)
- # mount (1)
- # off-topic (15)
- # pathom (25)
- # re-frame (17)
- # reagent (5)
- # remote-jobs (1)
- # shadow-cljs (92)
- # sql (10)
- # tools-deps (71)
- # xtdb (14)
How should api tokens be stored with re-frame? (yet another event-order question) Our current solution is something like this:
(reg-event-fx
::login-success
(fn [{:keys [db]} [_ token]]
{:db (assoc db :token token)
:dispatch [::fetch-some-data]}))
(reg-event-fx
::fetch-some-data
(fn [{:keys [db]} _]
{:http-xhrio {:method :get
:uri "/api/something"
:headers {:Authorization (:token db)}
:on-success [::something]
:on-failure [::something-else]}}))
but since the order between :db and :dispatch is undefined, the ::fetch-some-data event can be called before the token reaches the db (although it looks like db is currently run first). We don't really want to pass a token to every api function, because in almost all cases we can just grab it from the database. I've currently considered storing the token in an atom outside re-frame's store, but that feels slightly like a hack.The order is defined. :dispatch
is an effect which just calls dispatch
. Since it's not dispatch-sync
, you will have ordering as dispatch
just schedules the event.
so it's quaranteed that :db will be handled before the :dispatched event is handled
maybe I'll throw in a PR to clarify that point, right now the docs are a bit scary about that front :)
does the following paragraph sound correct? "Events dispatched by :dispatch
are guaranteed to be executed after the :db
side effect, so it is fine to simultaneously dispatch additional events and
update the database and expect it to be updated before the events are executed.
Only the order of effects is undefined, that is, events can be queued (not
executed) before the database is updated."
Sounds too specific to me. :db
is just one effect out of many, albeit a frequently used one. If it's for an FAQ entry, then it's probably fine.
But do note that I'm not affiliated with re-frame in any way, so don't take my words seriously.
Hi all, I'm looking at using re-frame and I like the idea of a set interface for querying and updating the app-db. Something that defines a structure for me so I don't have to (done this many times with Redux apps and it gets old!). I notice theres these, and I wondered if there are any favorites here: https://github.com/riverford/compound https://github.com/juxt/pull https://github.com/den1k/subgraph I'm not considering Datascript because there's no way to inspect it with devtools.
I've used subgraph for what you describe. The shape of the db could be improved (mainly for manual inspection), but other than that it was quite nice.