This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-01-10
Channels
- # announcements (1)
- # babashka (9)
- # beginners (372)
- # calva (3)
- # cider (9)
- # cljsrn (71)
- # clojure (57)
- # clojure-australia (2)
- # clojure-europe (26)
- # clojure-france (11)
- # clojure-nl (11)
- # clojurescript (5)
- # core-typed (1)
- # fulcro (33)
- # meander (3)
- # off-topic (1)
- # pathom (3)
- # re-frame (4)
- # reagent (6)
- # sci (1)
- # shadow-cljs (34)
- # xtdb (14)
Access tokens are intrusive to the handlers I write in a way which encouraged me to not put them in app-db sometimes. Making them atoms accessed via fx is a move towards fatter fx (e.g. io concern which includes state, fx which do "more" than simple AJAX requests). Con: more FX code which is technically harder to test. Pro: it reduces the "io" involved in event handlers - they can stay pure and focusd on business logic concerns. (Related concern which pushed me to fat fx was the number of promised based apis I needed to use to do meaningful fx actions - cljsrn app).
Can you describe what you mean by "Access tokens are intrusive to the handlers I write"?
Had a quick scan of my code for an example. Here's one I found which might help clarify where I'm coming from. This is wrapped as a "promise based" fx handler. https://gist.github.com/olivergeorge/86b1626b7241018d7439462fc4349a77 Turns out I do store the token in app-db in this app so it's more an example of where the IO/API interactions make more sense bundled together rather than driving every individual API call via an event handler request/response pair.
In conclusion... perhaps I can't answer your question directly! Oops.