Fork me on GitHub
#re-frame
<
2020-06-01
>
gmercer06:06:23

cross post from shadow-cljs

Jaakko Hannikainen12:06:26

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.

p-himik12:06:21

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.

Jaakko Hannikainen12:06:24

so it's quaranteed that :db will be handled before the :dispatched event is handled

p-himik12:06:13

"Quaranteed" - a timely typo. :) Yes, I would say it's guaranteed.

Jaakko Hannikainen12:06:55

maybe I'll throw in a PR to clarify that point, right now the docs are a bit scary about that front :)

Jaakko Hannikainen12:06:10

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."

p-himik12:06:46

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.

mruzekw20:06:13

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.

aisamu02:06:26

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.

mruzekw03:06:41

Thanks! I was also thinking of just pulling fulcro's database assuming no licensing issues...

mruzekw03:06:03

It's MIT so I'm sure I could make something work!

aisamu12:06:12

https://www.youtube.com/watch?v=ng-wxe0PBEg There's an official video for that!

💯 4
mruzekw18:06:27

Awesome! I saw that but misunderstood what it was for