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

Investigate support for @preDestroy #593

Open
remojansen opened this issue Jul 2, 2017 · 9 comments
Open

Investigate support for @preDestroy #593

remojansen opened this issue Jul 2, 2017 · 9 comments

Comments

@remojansen
Copy link
Member

Investigate @preDestroy see #587 (comment) for more info...

@theodesp
Copy link
Contributor

Remo, I find that very interesting.

Do you mean in general we need to provide some kind of a LifeCycleManager to handle the lifecycle calls or attach on* methods on the container similar to Windsor
https://github.com/castleproject/Windsor/blob/aa9b8b353ee2e533d586495eec254e216f800c09/docs/lifecycle.md?

What do you think of the usage of interceptors? That potentially will give a different way of doing the onActivation handling
https://github.com/castleproject/Windsor/blob/aa9b8b353ee2e533d586495eec254e216f800c09/docs/interceptors.md#interceptors.

Also, I was thinking of investigating of pairing them up with mixin style calls similar maybe to Django Rest Framework mixins http://www.django-rest-framework.org/tutorial/3-class-based-views/#using-mixins.

or this article

https://blog.mariusschulz.com/2017/05/26/typescript-2-2-mixin-classes

The idea is to attach mixins than are used independently for each lifecycle call.

What do you think?

@just-jeb
Copy link

I'd like this very much. The typical case for me is working with Observables. If you subscribe to an observable within a service that is not a singleton, you should unsubscribe once the service is destroyed, otherwise you'll get notifications in a service that doesn't exist anymore.

@miroslavvojtus
Copy link

I'd would like this feature as well.
We have a simmilar use case where we have a set of handlers for web socket messages.
Currently we have to ensure the handlers live in singletone scope all the time or manage the lifecycle ourself as we do not know when to detach the handlers.

Having @preDestroy would make the code more SOLID as now we have to handle some concerns out of bean definition.

@faustbrian
Copy link

@remojansen @parisholley has preDestroy been recently removed from any tags or npm releases? It seems to still exist on master but when I install 5.1.1 via NPM the preDestroy annotation is completely missing.

Screenshot 2021-06-05 at 18 25 47

@gradddev
Copy link

gradddev commented Sep 7, 2021

I also don't see onDeactivation handler for a Container instance and for a type binded in singleton scope.

@remojansen why isn't it in the NPM package?

@parisholley
Copy link
Contributor

#1319 - i don't think authors intend to push async changes until v6

@parisholley
Copy link
Contributor

i also have an old build of my initial PR here that has all of the working async functionality, though their may be slight differences between it and master: https://www.npmjs.com/package/@parisholley/inversify-async

@gradddev
Copy link

gradddev commented Sep 7, 2021

#1319 - i don't think authors intend to push async changes until v6

@parisholley, the documentation in the master branch is misleading: https://github.com/inversify/InversifyJS/blob/master/wiki/pre_destroy.md and https://github.com/inversify/InversifyJS/blob/master/wiki/deactivation_handler.md

@PodaruDragos
Copy link
Contributor

#1319 - i don't think authors intend to push async changes until v6

you are right. I don't know what happened with the wiki. hopefully we finish work on v5 soon. Then I think we can release a v6.
@dcavanagh

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

No branches or pull requests

9 participants