Fork me on GitHub

cleaned up the pathom-based dependency injection framework I had talked about in this channel earlier. no release yet but please give the SHA a try

👀 4

Interesting use-case for pathom! One thing I'm not clear on after reading the README: can I run two instances of :my.ns/server with different ports? My first impression is that there is a missing layer of indirection, because the fully-qualified names represent both the identity of a specific instance as well as the reference to the implementation.


thanks for the feedback! the keys are for maps that are stored in the pathom env, so I think that would be possible, you'd just have to call nx/init twice and keep both references to the returned env around. I think it'd be pretty much the same as how you'd do it in integrant? not sure what the use case would be though


It's good to know you can just call nx/init twice and have multiple envs (so no issue with global state), but these 2 envs would be share-nothing envs (i.e. you couldn't have a component dependent on two such servers.. since they're in separate envs and know nothing about each other). Integrant tries to resolve this issue with composite keys and composite references (


We've had use-cases where we want to spin up several instances of some component and give it unique global names; but then have an explicit separate step to bind those to local names for dependent components. (i.e. we can spin up both :some.ns/handler-1 and :some.ns/handler-2 and then explicitly pass in a dependency graph that says :component/x has a dependency: e.g. {:handler :some.ns/handler-1} )


This is why we ended up not using integrant, but a homegrown solution that borrows a lot from and


There's no right way to skin the DI-cat, so I'm always interested in learning about how others approach this problem. :)


that's an interesting problem. how many instances are we talking about, are they manually differentiated, or programatically generated?


why not just use clip?


afaict the best you can do with nexus now is just to make a different component with different inputs that shares implementation e.g. a common function for the body (so sharing implementation would be done at a level below the component, unlike in integrant where the component itself is the implementation to be shared). This seems mostly ok if it's only a handful of components, and in theory you could dynamically generate resolvers with a macro but that could be dicey. I haven't looked into the new dynamic resolvers much, maybe there's something there, especially wrt. passing in new dependencies.. intuitively it seems like pathom would be pretty good at dealing with fine-grained data sharing/differentiation requirements


I think the easiest change to facilitate that use would be to allow overriding pco/output , and then you could pass in a vector of inputs and return a pco/output with multiple keys


actually, aren't derived keywords essentially a join? I've only tested with flat queries but I wonder if what you describe is already addressed thanks to pathom's existing behavior