Feature - Unregister a token
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:
- https://github.com/microsoft/tsyringe/issues/96
- https://github.com/microsoft/tsyringe/issues/82
Example
interface ILogger {
type: string,
message: string
}
@injectable()
export class TestClass {
constructor(private logger: ILogger) { }
public info() {
console.log(`[${this.logger.type}] ${this.logger.message}`);
}
}
const instance1 = new TestClass({ type: "info", message: "test message info" });
const instance2 = new TestClass({ type: "error", message: "test message error" });
container.register("TestClass1", { useValue: instance1 });
container.register("TestClass2", { useValue: instance2 });
container.unregister("TestClass2");
const test1 = container.resolve<TestClass>("TestClass1");
test1.info();
const test2 = container.resolve<TestClass>("TestClass2");
test2.info();
The test1 should log the message without any problems, however the test2 will return an error message: Attempted to resolve unregistered dependency token...
Because unregister removed the corresponding key.
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.