-
Notifications
You must be signed in to change notification settings - Fork 620
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
wire: share dependency graph across injectors in the same package? #21
Comments
FWIW, in the meantime I'm using a technique similar to your Thanks! |
For reference, here is a minimal example that shows the behavior I'm describing in a dagger 2 project: https://github.com/drewolson/dagger_maven_example/tree/singleton_across_providers This is the test that asserts the behavior. |
Wire intentionally does not have a notion of subcomponents at the moment. In talking with the Dagger team, we discovered that subcomponents and scopes introduce a fair amount of complexity. As you say, you can get much the same behavior by returning the singletons from the first injector that creates them and then pass them to later injectors. This has the benefit of making the dataflow explicit, which for the examples we came up with, seemed like a net win. That said, we're very curious to see how folks will use Wire in real-world applications: if this does not scale, we might have to revisit. EDIT: I realized after looking more closely at your sample that the component itself is stateful (a detail I had forgotten about Dagger). My explanation above is still largely applicable: we want state to be explicit. |
Yes, this is where I was going with this conversation. Perhaps, in the future, there could be some kind of alternative injectors that are attached to a struct where state is tracked. I definitely agree that starting out simple and waiting for real-world experience reports is the right approach. Thanks again for this great library, I look forward to using it in my projects. |
@drewolson I found this issue 5 years later while looking up the same thing - how to share dependencies across injectors (eg reusing one DB connection-pool among multiple DAOs). Unfortunately, the links you posted are dead now and I'm not sure what you're referring to when you mention the " Could you please share some updated links (or better, sample code) to explain how you managed to share dependencies between injectors? Also, what is the " |
After some doing some more research, I found issue #260 where they basically resolve this issue by declaring an Sample code: type App struct {
*services.AuthService
*services.FooService
}
var daoSet = wire.NewSet(
dao.NewAuthDAO,
dao.NewFooDAO,
)
var svcSet = wire.NewSet(
services.NewAuthService,
services.NewFooService,
)
func InitializeApp() *App {
wire.Build(
dao.InitDB,
daoSet,
svcSet,
wire.Struct(new(App), "*"),
)
return nil
} Then after generating the For the
|
I was testing out wire and created a package with two injectors[1]. I noticed that each injector individually recreates the dependency graph. Other DI containers I've used (dagger, for example) allow sharing of singleton objects between different "entry points" to the graph.
Is this behavior intentional or is the goal to eventually allow "reusing" a graph across many injectors within a package?
[1] - https://github.com/drewolson/wiretest/blob/f34107974e871e45ac0f073c7878ab2d6e93b7c4/container/wire_gen.go
The text was updated successfully, but these errors were encountered: