tsyringe icon indicating copy to clipboard operation
tsyringe copied to clipboard

Feature - Unregister a token

Open wladimirgrf opened this issue 4 years ago • 12 comments

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.

wladimirgrf avatar Jan 25 '22 17:01 wladimirgrf

CLA assistant check
All CLA requirements met.

ghost avatar Jan 25 '22 17:01 ghost

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);

alper-batioglu avatar Feb 19 '22 19:02 alper-batioglu

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?

MeltingMosaic avatar Feb 25 '22 21:02 MeltingMosaic

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 avatar Aug 12 '22 21:08 wagnercsfilho

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).

wladimirgrf avatar Sep 18 '22 17:09 wladimirgrf

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 avatar Sep 19 '22 16:09 MeltingMosaic

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 avatar Sep 19 '22 23:09 wladimirgrf

@wladimirgrf updates about this?

wagnercsfilho avatar Jan 03 '23 23:01 wagnercsfilho

@wladimirgrf updates about this?

Hi @wagnercsfilho. No updates. I'm waiting for @MeltingMosaic response.

wladimirgrf avatar Jan 03 '23 23:01 wladimirgrf

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.

junioramilson avatar Jan 04 '23 15:01 junioramilson