kumarshantanu / dime Goto Github PK

View Code? Open in Web Editor NEW

30.0 4.0 1.0 116 KB

Dependency Injection Made Easy for Clojure

License: Eclipse Public License 1.0

Clojure 96.19% Emacs Lisp 3.81%

dime's Introduction

dime

Dependency Injection Made Easy for Clojure. This blog post explains the premise.

Rationale

Initializing and wiring up components in a non-trivial application could be a complex and brittle affair. It could be stateful, repetitive, messy or all of those. Dime aims to make that process less error-prone, repeatable and easy to reason about by implementing mostly-automated dependency injection/inversion.

Goals

Easy, push-model dependency injection
Flexible and easy lifecycle management
Thorough testability, avoiding pitfalls
Avoid mutation (except in development)

Caveats (Trade off)

Opinionated in favor of decoupling
Cascading dependencies (minimize with Onion Architecture or Functional Core, Imperative Shell approach)
Overhead of tagging all dependencies
Cannot inject in multimethods out of the box

Other work

The following projects take different approaches to dependency management:

Usage

Clojars coordinates: [dime "0.5.2"]

See Documentation

Discuss

Slack channel: #dime (you need an invitation from http://clojurians.net/ to join the Clojurian Slack team)

Development

Running tests:

$ lein do clean, test       # run tests in lowest supported Clojure version

License

Distributed under the Eclipse Public License either version 1.0 or (at your option) any later version.

dime's People

Contributors

Stargazers

Watchers

Forkers

vigneshsarma

dime's Issues

Add the ability to mark injectables as non-public

Something equivalent to defn-

Add support for multimethods

Allow exposing multiple entries

Currently, ^:expose exposes only one object/entry. In some cases, initialization functions (e.g. instrumentation functions that produce instrumented thread-pool/Ring-handler pair) may produce more than one entry to be exposed and used together.

The ^:expose metadata should allow a vector of entries, e.g. ^{:expose [:thread-pool :ring-handler]}. This may be applicable only with singleton-producing fns, typically annotated with {:post-inject dime.util/post-inject-invoke}.

Add shorthand version of expose meta data

Instead of having to do (defn ^{:expose :foo} foo ...), can we just do `(defn ^expose foo ...) instead? Also defaulting the expose name to be same as function name.

clj-kondo lint as rule

vscode plugin calva and probably most editors use clj-kondo to lint code files and require extra configuration to recognize defconst
Ive configured clj-kondo to lint defconst as defn and that seems to work well for me.

it appears that clj-kondo will search libraries for rules so that it can lint-as defn by automatically
https://github.com/clj-kondo/clj-kondo/blob/master/doc/config.md#exporting

Namespaced keywords

I love the idea. I was thinking however to avoid naming collisions I might need to use namespaced keywords.
For example, I found another cool library that generates API and basic type conversions from openapi spec or swagger files.
I may want to have multiple such api clients in my application and thus was thinking to namespace qualify

However, if I want to use a namespace keyword then things get a lot more verbose.
I noticed that the double colon ::keys syntax does not seem to work.
{::keys [swagger api-root authentication-header tracing-interceptor]
I either need to use ^{:inject ::swagger} swagger or [^:inject {:keys [ya.ynab/swagger ya.ynab/api-root ya.ynab/authentication-header ya.ynab/tracing-interceptor]}]

It would also be nice if I could somehow make namespace keywords the default as well so that I did not need to also override on expose (defconst ^{:expose ::martain} martain ...

Personally, I think maybe namespace keywords should be the default and maybe another implementation of dv/ns-vars->graph that prefers namespace keywords for ^:expose and ^:inject