pedestal

hlship 2025-04-29T17:31:19.303459Z

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.

jmv 2025-04-29T18:53:55.839109Z

i was wondering about this! the protocols and and to-interceptor function seem general enough that they could live in the core interceptor module.

hlship 2025-04-29T20:29:03.751519Z

Good point! There isn't anything Component about these and so moving the namespaces under the pedestal.interceptor namespace would be easier for everyone.

hlship 2025-04-29T20:30:02.692409Z

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.

jmv 2025-04-29T20:32:10.736399Z

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?

hlship 2025-04-29T20:37:46.546029Z

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.

jmv 2025-04-29T20:40:36.826389Z

yeah that sounds great

jmv 2025-04-29T20:41:11.829109Z

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

hlship 2025-04-29T20:43:11.871549Z

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

👍🏻 1
2025-04-29T22:50:14.998799Z

I was wondering whether definterface needed the protocol names. definterceptor being already specialized, it could allow :enter and :leave in place of protocol names.

hlship 2025-04-29T22:51:17.022579Z

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.

hlship 2025-04-29T22:51:25.626709Z

Still thinking about it, though.

2025-04-29T22:53:17.915909Z

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.

2025-04-29T22:53:26.774679Z

I mean re-evaluable

2025-04-29T22:54:49.920819Z

Am also a big fan of Component

hlship 2025-04-29T00:33:10.393539Z

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)))

hlship 2025-04-29T00:34:35.429019Z

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.