This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-11-04
Channels
- # announcements (4)
- # babashka (15)
- # beginners (147)
- # bristol-clojurians (8)
- # calva (6)
- # chlorine-clover (39)
- # clj-kondo (29)
- # clojure (95)
- # clojure-australia (1)
- # clojure-berlin (1)
- # clojure-europe (24)
- # clojure-nl (3)
- # clojure-spec (185)
- # clojure-uk (98)
- # clojured (2)
- # conjure (3)
- # core-async (26)
- # datomic (11)
- # etaoin (1)
- # events (1)
- # fulcro (26)
- # graalvm (3)
- # graphql (4)
- # jobs (7)
- # jobs-discuss (1)
- # kaocha (12)
- # leiningen (21)
- # malli (2)
- # meander (2)
- # parinfer (3)
- # pathom (3)
- # pedestal (5)
- # remote-jobs (2)
- # shadow-cljs (71)
- # spacemacs (2)
- # sql (4)
- # tools-deps (22)
- # tree-sitter (1)
- # vim (2)
- # xtdb (5)
I was thinking it could make sense to set my own namespaced key in the service map and allow my interceptors to read configuration from that. Is that advisable? And is it even possible for an interceptor to read keys in the service map?
I use this add-service-map in most of the apps that i develop https://github.com/souenzzo/graph-demo/blob/master/src/main/souenzzo/graph_demo/core.clj#L156
@U2J4FRT2T Perfect! I guess this does not come built in then. Do you also keep your own custom keys in the service map or do you just this interceptor to read some of the standard keys?
The point was just to have an alternative to calling a bunch of interceptor constructor functions. Integrating with the Pedestal service map would also gather more configuration in the same place. So for instance I might write:
{::http/type :jetty
::http/port 8080
::http/routes #{...}
:my.own.ns/config {...}}