Fork me on GitHub
#reitit
<
2022-12-20
>
robert-stuttaford07:12:36

in middleware, one can use binding e.g. (binding [my.datomic/transacting-user-id <some value>] (handler request)) how does one achieve the same effect with interceptors in reitit, given that you're not directly calling the next middleware in a way that can be wrapped by binding? edit: i see pedestal's interceptors have explicit support, but seippari does not

ikitommi15:12:47

ā€¢ You can use pedestal with reitit, how does it do this? ā€¢ reitit mw chain composes just like a ring mw chain, so binding should just work? Create a mw that does the binding for the next gabdler handler and add to the chain?

robert-stuttaford15:12:43

specifically wanting to do this with interceptors! i'm going to have a go at giving seippari bindings support - i'll share whatever i learn šŸ˜„

šŸ‘ 1
robert-stuttaford11:01:52

(defn session-user-datomic-binding-interceptor []
  {:name  ::session-user-datomic-binding
   :enter (fn [{{:keys [user]} :request :as ctx}]
            (update ctx :bindings merge {#'datomic/*transacting-user-id* (:db/id user)}))})

robert-stuttaford11:01:18

fyi @ikitommi - if this is something you'd like a PR for, lmk!

robert-stuttaford09:12:33

am i meant to be calling sieppari.context/terminate when i want an interceptor to short-curcuit a response @ikitommi? edit: i do this and it works. would be great for reitit's docs to include a note about this! the reason i ask is because it seems to leak the design of the the contract created by providing an executor (i.e i would have expected the executor protocol to include a function for it, and reitit to provide an api to invoke it, to match with the rest of the executor abstraction, and in so doing, avoiding the need to calll seippari outside of providing the executor)

āž• 1
Thomas Moerman12:12:40

Well spotted, I've been using assoc :queue nil for that. This is cleaner.

ikitommi15:12:40

can't recall, sorry