This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-05-06
Channels
- # announcements (7)
- # aws (8)
- # babashka (9)
- # babashka-sci-dev (11)
- # beginners (37)
- # calva (50)
- # cider (15)
- # clj-kondo (30)
- # clj-otel (3)
- # cljdoc (16)
- # cljs-dev (26)
- # cljsrn (4)
- # clojure (168)
- # clojure-doc (1)
- # clojure-europe (17)
- # clojure-gamedev (4)
- # clojure-nl (3)
- # clojure-norway (1)
- # clojure-spec (17)
- # clojure-uk (16)
- # clojurescript (27)
- # community-development (3)
- # css (3)
- # cursive (9)
- # datomic (25)
- # emacs (1)
- # events (4)
- # fulcro (2)
- # google-cloud (2)
- # graphql (11)
- # gratitude (9)
- # humbleui (16)
- # hyperfiddle (2)
- # jobs (1)
- # london-clojurians (1)
- # lsp (16)
- # malli (2)
- # off-topic (71)
- # pedestal (4)
- # polylith (9)
- # portal (94)
- # reagent (6)
- # reitit (2)
- # releases (1)
- # remote-jobs (2)
- # sci (9)
- # shadow-cljs (49)
- # spacemacs (8)
- # tools-build (2)
- # tools-deps (39)
- # vim (7)
- # xtdb (6)
Every larger project tends to accumulate a handful of namespaces with small general purpose or utility functions that are used throughout the project. Something like https://github.com/weavejester/medley or https://github.com/ptaoussanis/encore . I was thinking about how to best represent them in terms of polylith abstractions, and it seems they are more close to a 'library' concept, rather then a 'component' one. Having interface for those small functions brings little to no benefit, yet it is useful to have them closer to the project and not publish them as a full fledged versioned library. My idea is to store such namespaces in the 'libraries' directory inside the workspace (e.g. 'libraries/math', 'libraries/coll'), and then refer to the from component or base deps.edn files, e.g. {:deps {foo/math {:local/root "../../libraries/math"}}}
Is this in your opinion fine or should I rather meticulously define interface for every small general purpose functions that I'm not ready to publish as a part of a totally separate library?
Agreed. I've found that its possible to implement methods directly in the interface and add the abstractions later when needed. Clients are unaffected when the implementation is split out.
Yes, it’s okay to put implementation code directly in the interface if you think delegating to an implementing namespace is not needed or add any value. If you for example put your util functions in a util
component, then an option is to group the different util functions in different sub namespaces (especially if you have many functions).
I've been working with three tools that could potentially work together to create a full-stack development environment but have not yet integrated them properly:
- https://polylith.gitbook.io/polylith/
- https://kit-clj.github.io/
- https://fierycod.github.io/holy-lambda
Each is great but together, they'd be incredible. However, due to some differences in implementation, they're not easy to integrate yet.
- Polylith https://github.com/polyfy/polylith/issues/206 src
while Kit uses src/clj,src/cljs,src/cljc
.
- Holy Lambda works with https://github.com/FieryCod/holy-lambda-ring-adapter/blob/master/examples/native/src/example/lambda.clj while Kit is built around https://kit-clj.github.io/docs/integrant.html.
I'm curious if anyone else has attempted to tie these together?
The author of Holy Lambda kindly provided a way to incorporate Integrant: https://clojurians.slack.com/archives/C01UQJ4JC9Y/p1651820869228109?thread_ts=1651788189.530139&cid=C01UQJ4JC9Y