- Simplified some util name (only relevant to folks customizing handler behaviour)
- Merged `format-signal->edn-fn`, `format-signal->json-fn` to single `pr-signal-fn`
Previously:
It was possible to provide a vector of middleware fns when creating
signals or adding handlers, e.g.:
(event! ::ev-id1 {:middleware [fn1 fn2 ...]}),
(add-handler! ::handler-id1 <handler-fn> {:middleware [fn1 fn2 ...]})
After this commit:
Middleware is always expected to be a single fn, or nil.
A `comp-middleware` util has been added to make it easy to compose multiple
middleware fns into one.
Motivation:
The previous (auto-composition) behaviour was nice when adding handlers,
but incurred a (small but non-trivial) runtime cost when creating signals.
The actual benefit (convenience) of auto-composition is very small, so
I've decided to just remove this feature and add the `comp-middleware` util.
Note that I ruled out the option of doing auto-comp only when adding handlers
since that've meant an inconsistency and so complexity for little benefit.
Thanks to @AdamFrey for reporting this issue!
Ref. <https://clojurians.slack.com/archives/C06ALA6EEUA/p1713805333272469>
Previously:
Attempting to run AOT'd code using Telemere would result in errors like:
"Attempting to call unbound fn: #'taoensso.telemere.handlers.open-telemetry/handler:open-telemetry-logger"
The approach I was using of conditionally requiring namespaces and then aliasing vars seems to be inherently
fragile under AOT, and was leading to the remote source var being unbound.
With this commit I've now switched to a simpler approach - where we conditionally require namespaces *without*
the need for any aliasing.
