-
Notifications
You must be signed in to change notification settings - Fork 724
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
Container.resolve should resolve in that container #1338
Comments
Hi @tonyhallett , I think a child container is being created to avoid adding a binding to the original container. I think users don't expect their bindings to be modified so I wonder if we should take this approach. What do you think @PodaruDragos , @dcavanagh ? |
Agreed - it is necessary for there to be no binding to be able to use resolve more than once. The solution in the pull request - bind, get, unbind has the same behaviour as the current code. The example I provided, with a derived container, is real but was mainly chosen for illustration purposes. Most importantly, the issue can manifest if we decide to change the internals of the Container class by setting some private property. At the moment there is no such problem as the child gets the options of the parent and the middleware is copied across. |
But if the user had already set a binding for that type we would be removing its binding, is that right? |
That is true but is that the purpose of resolve ?
Why would you bind and then want to avoid the resolution logic ? You are right though, the solution does not have the same behaviour as the current code. |
I think there's no good reason to perform the operation, but the operation could be performed and I think we should try to provide the right behavior
Yeah, that would work :) |
Changed to only bind / unbind is not already bound. |
https://github.com/inversify/InversifyJS/blob/master/wiki/container_api.md#containerresolvetconstructor-interfacesnewablet-t
It is like it but is resolved in the Context of a child container. This is not mentioned in the documentation and I would expect that most people would expect that this is just sugar for below
In most scenarios the difference is not important but it is if you are expecting context.container to be the container that you called resolved upon.
Soln - resolve from the same container !
The text was updated successfully, but these errors were encountered: