Yeah you’re right sorry It git removed when I was trying to remove unnecessary code
The thing is that the dependency on state-component
is specified in the defrecord for IM-Proto-0
and then everywhere else - specially where this code is included as a library- I’m creating a system that has a IM-Proto-0
component I should supply the dependency using component/using
.
How could I make it easier for clients of this library to use and maintain their code using my components?
But every use could be injecting a different thing for the state-component
Yeah you’re right but the thing is how should they know that there is a state-component
dependency at all?
I think I didn’t explain the problem well.
We wanted the im.access/create
multimethod to hide implementation details of a component whose different versions may have different component dependencies. For instance one implementation uses only a Hazelcast client component and another uses Redis in conjuction with a Postgres. Which is determined dynamically by their configurations.
The dependencies have to be computed before you start
the overall system.
In some of our projects we used to construct a system map at each component level and put the component/using
there and merge these subsystem at top level (we followed an article on best practices of using component library) but that also made the code not exportable as a library since we were limiting the users of the components in their injection (they had to name the dependency exactly what we had set for the component)
If the dependencies are derived from the configuration, then you need to load the configuration first, then use it to build the using
dependency map.
Or you need to abstract over the things that can vary.
Do you have the exact same API over Hazelcast that you have over the Redis/PostgreSQL combo?
Hmm no they’re different There are two separate very different implementations for those
Either way, you're going to need to process the configuration first, use that to drive the construction of the components and/or the using dependency map, and then start
it.
So it might be that you need a component, based on configuration, that when it start
's up produces your actual system component with all its dependencies, and then you start
that?
Yeah you’re totally right That seems a lot better Thanks a lot @seancorfield