Open wladimirgrf opened 2 years ago
It is a missing feature. I have been using stuff like below which I am nervous about. It would be good to use it legally. 😀
(container as any)._registry._registryMap.delete(IViewModel);
(container as any)._registry._registryMap.delete(IState);
I have always been pretty leery of this feature. I get that it might be useful for testing, but I fear that it would create situations where an object can be resolved but not be able to be resolved later. @xapphire13, what do you think?
Hi guys, any update on this Pull Request? We need this feature in our React application to remove a ViewModel Singleton class from memory when a component is destroyed.
Hi guys, any update on this Pull Request? We need this feature in our React application to remove a ViewModel Singleton class from memory when a component is destroyed.
@wagnercsfilho we are waiting for @Xapphire13 feedback. But you can use the same implementation of my branch to resolve the ViewModel (creating a proprietary npm package). Until this version is merged with the official tsyringe package (If the developers agree with this implementation).
Alright, I think we can accept this PR - please update the readme, and I'll accept it and push out a new version this week.
You may need to rebase too (I'm not totally sure)
Alright, I think we can accept this PR - please update the readme, and I'll accept it and push out a new version this week.
You may need to rebase too (I'm not totally sure)
@MeltingMosaic I pulled the latest updates and added a description for the unregister
in the Readme.
Let me know if the PR needs any further changes.
@wladimirgrf updates about this?
@wladimirgrf updates about this?
Hi @wagnercsfilho. No updates. I'm waiting for @MeltingMosaic response.
Just sharing what I'm facing with the tsyringe and AWS lambdas. Every request, I need to register a runtime value to be used inside the lambda code, that's ok and works perfectly. But when a next request comes in, the value registered in the last request is still present and in this scenario it can be considered as a data leak. In this case I cannot allow a value from a previous request to be present in the next requests.
That's why I need the unregister
function. At the end of each request, I would call the unregister function to avoid that problem.
This is not a big problem yet because I'm overwriting the old runtime value in every request. But there could be other scenarios that can be very problematic.
Added this to tsyringe-neo
There are features in tsyringe for removing/cleaning all instances. It is not possible to choose a specific token to delete.
This pull request enables unregister a token. Solving two issues:
Example
The
test1
should log the message without any problems, however thetest2
will return an error message:Attempted to resolve unregistered dependency token...
Because unregister removed the corresponding key.