Skip to content
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

Feature - Unregister a token #190

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

wladimirgrf
Copy link

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

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.

@ghost
Copy link

ghost commented Jan 25, 2022

CLA assistant check
All CLA requirements met.

@alper-batioglu
Copy link

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

@MeltingMosaic
Copy link
Collaborator

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?

@wagnercsfilho
Copy link

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.

@wladimirgrf
Copy link
Author

wladimirgrf commented Sep 18, 2022

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

@MeltingMosaic
Copy link
Collaborator

MeltingMosaic commented Sep 19, 2022

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)

@wladimirgrf
Copy link
Author

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.

@wagnercsfilho
Copy link

@wladimirgrf updates about this?

@wladimirgrf
Copy link
Author

@wladimirgrf updates about this?

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

@junioramilson
Copy link

junioramilson commented Jan 4, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants