This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2024-01-27
Channels
- # announcements (24)
- # babashka (26)
- # beginners (8)
- # calva (8)
- # clojure (78)
- # clojure-europe (1)
- # clojure-norway (22)
- # clojurescript (14)
- # datascript (5)
- # datomic (8)
- # fulcro (22)
- # helix (9)
- # humbleui (11)
- # malli (4)
- # off-topic (28)
- # pedestal (5)
- # reitit (10)
- # shadow-cljs (2)
- # tools-build (8)
- # tools-deps (9)
Hey folks,
A question about pedestal with components as I am struggling with something that seems very simple. Basically, I am trying to build a simple application, and as an example, I have a :db
component that I want to receive in my application routes context, so I can use it to connect to my db. I tried to do something as explained https://github.com/stuartsierra/component/blob/master/README.md#web-applications, basically creating a component that will kind of "group" all components that I want to passthrough. But still, I am not being able to retrieve these components in the pedestal routes. Could you point me in the proper direction (maybe providing examples, specific documentation, etc.) ?
The linked page has excellent advice (it says: create the "handler" function as a closure over [the db, etc.etc.]) although in Pedestal you want to create interceptors (not handlers) in a closure with the db, etc.etc.. The Pedestal "context map" is something else. It carries outputs of one interceptor for use as inputs to other interceptors... enabling interceptors to reason collectively. See Pedestal docs at http://pedestal.io/pedestal/0.7/guides/what-is-an-interceptor.html#_sharing_information_between_phases . Just add your db as a parameter to the timing-interceptor example function and you're all set.
Thank you very much. I was able to make it through, I was missing somehow that "the thing" of pedestal were interceptors. By adding an interceptor including the :db
(and others) elements to the context it was then propagated!
Something new in 0.7 is the ability to specify an initial context as part of the service map; this is where you’ll inject dependencies such as :db, that will be available to all interceptors. This is easier, and microscopically more efficient than, adding an interceptor to inject such dependencies. But I’m also a fan of each handler being a component with its own specific dependencies. That appeals to me for an organizational viewpoint (it lets you get rid of dependencies that aren’t used because you can see if they are used or not much more easily). A component (i.e., from Sierra’s library) can implement IntoInterceptor to expose itself as an interceptor. I have some plans to do some examples in the documentation, a component-oriented one using the IntoInterceptor trick would be a good one.
Amazing @U04VDKC4G. As soon as you have some examples, I will be very glad to take a look. Thanks for the details as well!