Because most interceptors only implement one of the three, and if you have one protocol that forces you to implement all three, you undo some significant optimizations inside interceptor.chain.
i was wondering about this! the protocols and and to-interceptor function seem general enough that they could live in the core interceptor module.
Good point! There isn't anything Component about these and so moving the namespaces under the pedestal.interceptor namespace would be easier for everyone.
I chatted with Sandra about this, and she was concerned about confusion about what definterceptor does, which I may address by making the to-interceptor public and describing what it does, and then discuss definterceptor in terms of to-interceptor.
with this style, do you construct handlers with dependencies attached to the record, like a closure basically? contrasting with the style of injecting dependencies into the context during execution?
I'll be working on a "Using Pedestal With Component Part 2" to cover what it looks like. Essentially, your might have a Routes component that provides your routes, and it has dependencies on interceptor and handler components, which is uses when building the route fragment. Those components have dependencies on all the rest of the stuff. Unlike the current tutorial, there's no "big ball of mud" :component that everyone see; each interceptor gets just the dependencies it needs to do its one thing.
yeah that sounds great
i think knowing which keys have some critical dependency for a later interceptor down the line has been a source of bugs in the past
Big ball of mud is easier, of course. But more organization gives you the structure of your application ... tools can use this, or even visualize it: https://github.com/walmartlabs/system-viz
I was wondering whether definterface needed the protocol names. definterceptor being already specialized, it could allow :enter and :leave in place of protocol names.
I thought about, having special opts for enter/leave/error BUT that will confuse Cursive and clj-kondo. May be able to fix clj-kondo, but it will make for a bad Cursive experience.
Still thinking about it, though.
I have used a reloader (not whats-its-name but another, which is based on tools.namespace, which also uses remove-ns) but only in connection with stopping and restarting. In short, emergencies. Usually I prefer to just re-evaluate individual forms, except defrecord. Therefore I was in the habit of declaring interceptors, that only delegate enter and leave to ordinary functions, which are reloadable.
I mean re-evaluable
Am also a big fan of Component
Initial work (no tests, no docs) on Component integration: https://github.com/pedestal/pedestal/tree/hls/20250428-component
tl;dr; (definterceptor upcase-body p/OnEnter (enter [_ context] (update-in context [:request :body] string/upper-case)))
Basically, it is a macro that generates a defrecord and adds an extension for the IntoInterceptor protocol. There's protocols Handler, OnEnter, OnLeave, and OnError.