destructor option for service providers

[pjordaan]

[ ] bug report => search github for a similar issue or PR before submitting
[X ] feature request
[ ] support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Current behavior
See example below:

@Injectable()
export class GlobalServiceProvidedInBootstrap {
    public subscribe(f: Function);
    public unsubscribe(f: Function);
}

export function callback() {
};

@Injectable()
export class ServiceProvidedInElement {
    constructor(public service: GlobalServiceProvidedInBootstrap) {
        service.subscribe(callback);
    }
}

@Component({
    selector: 'example-tag',
     providers: [ServiceProvidedInElement]
})
export class ExampleTagComponent {
    constructor(private s: ServiceProvidedInElement) {
    }
    public ngOnDestroy() {
        this.s.service.unsubscribe(callback);
    }
}

The problem I'm having in similar code is that the moment this component is destroyed, there is no way for me to unsubscribe ServiceProvidedInElement from GlobalServiceProvidedInBootstrap unless I use ngOnDestroy in the component.

Expected/desired behavior
The expected behavior is that when I declare my providers, I should be able to set a callback to destroy my service provided. So instead of using ngOnDestroy I could do it like this:

export SERVICE_PROVIDED_IN_ELEMENT_PROVIDERS = [
    {
        token: ServiceProvidedInElement,
        useDestructor: function (element: ServiceProvidedInElement) {
              element.service.unsubscribe(callback);
        }
    }
];

[DzmitryShylovich]

Services already have ngOnDestroy hook so it can be closed.

[zoechi]

I have never seen it mentioned that ngOnDestroy is supported on services.
The docs say "when a directives or pipe is destroyed" https://angular.io/docs/ts/latest/api/core/index/OnDestroy-class.html

[DzmitryShylovich]

http://plnkr.co/edit/AgBYNxmW1aIPiDFAr5iu?p=preview

[zoechi]

I guess the docs on the interface should be updated then

[maxkoretskyi]

@DzmitryShylovich, there is no longer logging in the console in the plunker you referenced when a component is destroyed. Has anything changed?

[willshowell]

@MaximusK there was a change in 4.0.0-rc.4 that made providers instantiate lazily.

Updated plunker: http://plnkr.co/edit/FA9bIc3dEiHundiKx95M?p=preview

[maxkoretskyi]

@willshowell , thanks! So as I understand the ngOnDestroy is called on a service when it's destroyed. But when is it destroyed? When the component that declared the service in providers gets destroyed? And does it mean that services defined on modules will never be destroyed?

[willshowell]

@MaximusK From what I understand, yes to both questions. For our case, we wished for a service to be destroyed once navigating away from any of the module's routes. This required providing (and injecting) the service in a wrapper <router-outlet> component.

[gparlakov]

@willshowell @MaximusK I have the same observations. Service gets its ngOnDestroy() called only when provided in a component. So the Service will never get destroyed if provided in module.

And I ask - does that matter - if you "destroy" the ng app - that means you have closed that page so effectively the garbage collector will clean up all eventually.

[maxkoretskyi]

@willshowell , thanks. Interesting approach with a router-outlet wrapper. Can you maybe share more details?

@gparlakov , thanks for the confirmation

[willshowell]

@MaximusK it works like this:

@Component({
  ...
  providers: [MyService],
  template: '<router-outlet></router-outlet>'
})
export class MyNavWrapperComponent {
  // Must inject to instantiate service for all child routes.
  // When this component is destroyed, the service will be too.
  constructor(service: MyService) { }
}

routes: Routes = [
  {
    path: '',
    component: MyNavWrapperComponent,
    children: [ ... ],
  }
]

It's important to note that using empty routes like this may introduce confusing behavior with relative routes since that empty route is still considered a UrlSegment. See #17957.

[maxkoretskyi]

@willshowell , thanks for sharing

[mcgraphix]

@gparlakov - I don't think we should assume that destroying an app only happens when you close the window or navigate away. Let's say your app is loaded into a portal with potentially other apps. IMHO - removing the dom node that the app is bootstrapped on should destroy everything including services provided via modules.

[aks1994]

Is there any manual way to destroy the services provided in a module?

[gparlakov]

What's the use case? 1. Suppose we did destroy it (kill off its reference for example). Is it expected to get renew-ed upon next it is needed? 2. Or maybe the service itself can be a creator of services (I'd say factory but with the existence of *provide... useFactory *it would be confusing and misleading). 3. Some other use case?

…

On 14 April 2018 at 15:53, aks1994 ***@***.***> wrote: Is there any manual way to destroy the services provided in a module? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#11228 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADUiVyVnnNioZAnlwIk5LCUJNnj3nYe4ks5tofEygaJpZM4Jycxn> .

-- Георги Парлъков / Georgi Parlakov

[aks1994]

@gparlakov My use case is that I have a service that I want to be associated with a component (or only inside a lazy module that opens post logging into my app). However, if I provide it in the component (the main wrapper component post login), I cannot access it in route resolver guards. So I have to provide it at the lazy module level but then it becomes a global service to some extent. Even upon logout from my app (routing to a component outside the lazy module), the service is not destroyed so I have user data in that service which is still in memory. Sure, I can't access it directly from outside the lazy module but it is still not deleted permanently and is reaccessed upon logging in (even with a different log in)

[gparlakov]

@aks1994 This is my understanding of what happens:

1. Whenever the lazy module is first loaded the service gets instantiated and placed in the module's injector
2. Every subsequent request to that module (to its main component) would use that same instance

Right?
(I am not aware of a way of instructing angular to kill off any module or its providers.)

Provided that you already have guards: Maybe inside of a route guard that is executed on the way in you can clean up/initialize the service i.e. every time user wants to go back to this component the service-s state gets zeroed out.
Alternatively the service could become a provider of a service-s instead of doing the work itself.

[aks1994]

Okay, yes I don’t think there is a way either but just wanted to check. For the clean up/initialise step that you mention, is there a way to do that besides keeping track of all the variables and setting them to null? Do you mind elaborating a little bit more on how the service could be a provider of services and how that would help here? I’m not too familiar with this. Thanks for your help!

…

On 15-Apr-2018, at 2:48 AM, Georgi Parlakov ***@***.***> wrote: @aks1994 <https://github.com/aks1994> This is my understanding of what happens: Whenever the lazy module is first loaded the service gets instantiated and placed in the module's injector Every subsequent request to that module (to its main component) would use that same instance Right? (I am not aware of a way of instructing angular to kill off any module or its providers.) Provided that you already have guards: Maybe inside of a route guard that is executed on the way in you can clean up/initialize the service i.e. every time user wants to go back to this component the service-s state gets zeroed out. Alternatively the service could become a provider of a service-s instead of doing the work itself. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#11228 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AcygdMZwhBD-MQ2w5PDGRyf82pPeM_zgks5tou1VgaJpZM4Jycxn>.

[gparlakov]

@aks1994

For the clean up - I would do it just like you said - set everything back to initial value. And do it /initialize it/ every time you want to use it. The risk is that there might be a confusion about whether or not the state was initialized - so I'd do it every time.

Elaborating on the provider of services: here. Notice the 'the-service.service.ts' and how it is provided in the module and used in hello.component.ts and app.component.ts. It is providing a new instance for every time we call the .provideAService('somestring') method.

[aks1994]

@gparlakov

Okay, makes sense. Thanks for the help and sharing the info on provider of services!

[jscharett]

This seems like a bit of a hack, imo. It would be nice to simply specify my provider in the module and allow the module to destroy it when the user exits the module. The current design can be left in place for backwards compatibility, but why not allow me to specify that the provider gets destroyed every time the use exits the module?

[mlc-mlapis]

@jscharett ... what is the term exit from the module? What it means for you.

[jscharett]

@mlc-mlapis When my route changes to leave a lazy loaded module. I understand that lazy loading only delays the loading of the module and does not "unload" it when navigating away from it. It just seems like there should be a clean way to "reset/destroy" a provider used in a lazy loaded module.

For example, in my app, we have a lazy loaded module that when the user enters, create a provider for storing various data. The provider is used across multiple components, so its created in the ng module. When the user navigates away from the module back to the home page, I am required to implement a guard so that I can "cleanup" the data stored in the provider. Not a huge issue, but just seems like it would be beneficial if you could specify a provider that could be destroyed upon exiting the module/route.

It was not intuitive to me that my provider would continue after navigating away from the module.

[Sahil624]

Hi !
I am also facing same issue. My provider stores some user data that is shared among one or more components for a logged in user. When user logs out and login with any other account user data of previous user is shown in every component.
Any solution or workaround available ?
Thanks for any help.

[shikharseth]

@Sahil624 any solution you found out for your use case?
It would be great if you can help me in that too

[gparlakov]

@Sahil624 @shikharseth One approach would be providing the provider in the component that needs it. Then It will get instantiated and destroyed along with the component. I am assuming this component would get destroyed when user logs out - because app navigates to logout screen for example

[shikharseth]

@gparlakov the use case is quite different here. Since, I require service data to be shared across components so I need to mention my providers inside my app.module.ts. Your's approach wont let me do the same.
Data sharing is working fine as to my need across different module and component.
But the scenario is when I logout from one user and login with different app.module don't get destroyed(though component do), due to this service data remains intact and I get same data of my last user on sigining with different user.
I want to destroy data from my services data defined in app.module

[gparlakov]

I want to destroy data from my services data defined in app.module

@shikharseth It appears that you need to use the onDestroy lifecycle hook to clean up your service.
Or the logout method needs to actually clear the state of that service. Either way I would create a method on that service onLogout and call it.

[Sahil624]

@Sahil624 any solution you found out for your use case?
It would be great if you can help me in that too

Hi !
Sorry didn't knew about your reply earlier.I did this by making an event service. It was basically a subject in service and I subscribed it in my services which I wanted to destroy (More like i wanted to clear data that was cached in that service). In my logout function i emitted a event (subjectName.next()). Whenever is received anything in by event subscription I cleared my data.
This is more of a hack. But it was working for me. I cannot share my code at this time but i hope I could explain it will. Feel free in any case of doubt.
Thanks

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}