You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be nice if you could auto resolve from another container. Example:
typeMessagestringparent, _:=di.New(di.ProvideValue(Message("Hello from parent")))
child1, _:=di.New(di.Chain(parent))
child1.Invoke(func(mMessage) { fmt.Println(m) })
This would let us have common injection providers in a parent, but still have some child Containers that can inject some variations. Some DI systems call these DI scopes I think.
The text was updated successfully, but these errors were encountered:
I have heard about scopes in DI containers and seen several implementations. But in my practice, I have not encountered a real need to separate components into several containers, especially in Go applications, which are primarily small. I think that scopes are necessary for large codebases with many modules, which components must be isolated from each other.
Maybe you have a real-life example where this functionality would be helpful? We could discuss it :)
We have a case where we support updating the configuration of the server, when the reconfiguration occurs we need to recreate all the services as even the di.Options can change in the child container.
Right now we are pulling objects out of the parent Container and manually putting it in the new child container. It works, but it's not beautiful.
It would be nice if you could auto resolve from another container. Example:
This would let us have common injection providers in a parent, but still have some child Containers that can inject some variations. Some DI systems call these DI scopes I think.
The text was updated successfully, but these errors were encountered: