This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-01-16
Channels
- # announcements (2)
- # babashka (51)
- # beginners (165)
- # biff (39)
- # clara (1)
- # clj-kondo (20)
- # cljsrn (6)
- # clojure (64)
- # clojure-belgium (11)
- # clojure-conj (2)
- # clojure-europe (12)
- # clojure-nl (3)
- # clojure-norway (7)
- # clojure-uk (6)
- # clojurescript (11)
- # conf-proposals (1)
- # conjure (1)
- # core-async (19)
- # cursive (6)
- # data-science (16)
- # datomic (6)
- # deps-new (4)
- # fulcro (60)
- # funcool (3)
- # graalvm (9)
- # helix (14)
- # introduce-yourself (4)
- # jobs-discuss (13)
- # joyride (1)
- # kaocha (2)
- # malli (12)
- # off-topic (25)
- # polylith (9)
- # portal (3)
- # practicalli (1)
- # rdf (43)
- # re-frame (7)
- # reagent (5)
- # releases (5)
- # remote-jobs (8)
- # sci (5)
- # shadow-cljs (42)
- # squint (6)
- # xtdb (5)
What's the general opinion regarding common utilities and where to put it? For example: Imagine a namespace like this: https://github.com/plumatic/plumbing/blob/master/src/plumbing/core.cljc Full of functions like:
(defn sum [xs] (reduce + xs)
Normally I'd have a libs
folder with such namespaces and just require them as usual.
A component with these common functions would be required everywhere over time.
And hiding everything behind an interface
ns and forwarding the calls, doesn't seem to add much value right now.
Am I wrong?Not sure if it is considered good Polylith practise, but I have some local libraries in a libs
dir. For these libraries I am somewhat missing features of Polylith (like incremental testing), but putting these libs in components doesn’t feel right either.
Curious to hear others opinions about this as well.
If you want to use components, you can define the implementation in the interface namespace, or have an interface folder, with (implementation) namespaces inside. For example acme.utils.interface.math
I agree it feels a bit odd
yeah I have one case where I do that. And for protocols and multimethods I use acme.utils.interface.protocols
and for implementation of the “protocols” i used acme.utils.interface.extensions
. But for libraries I have not found something I liked
One solution would be to allow setting :interface-ns
per component. For libraries, one could use the top-level ns (e.g. acme
) and get all the code from the component as an interface. Or a way to mark a component as a :library
and drop the whole interface convention from those.
We do what Teemu suggests and just have the implementation in the interface
file. You don't have to have a separate impl
file for every interface -- you could always refactor parts of that later.