ngneat / until-destroy Goto Github PK

Components that reference their classes in themselves stop working. For instance - the use case of providing a custom Angular Material MatFormFieldControl which references the component class in the Component decorator:

@Component({ ... providers: [{provide: MatFormFieldControl, useExisting: MyTelInput}], }) @UntilDestroy() class MyTelInput implements MatFormFieldControl<MyTel> { ... }

(from: https://material.angular.io/guide/creating-a-custom-form-field-control)

It will throw an exception like the following:

my-tel-input.component.ts:XX Uncaught ReferenceError: MyTelInput_1 is not defined

Removing UntilDestroy and untilDestroyed makes it work again.

I'm using nrwl NX and jest.
When I run jest I'm getting

TypeError: Cannot read property 'onDestroy' of undefined


node_modules/@ngneat/until-destroy/bundles/ng:/@ngneat/until-destroy/lib/until-destroy.ts:32:48
at Object.__decorate (../../../../node_modules/tslib/tslib.js:93:99)

Has anything changed in the latests RC's that could cause this to happen?

Why?

package.json:

  "dependencies": {
    "@angular/animations": "^5.2.0",
    "@angular/common": "^5.2.0",
    "@angular/compiler": "^5.2.0",
    "@angular/core": "^5.2.0",
    "@angular/forms": "^5.2.0",
    "@angular/http": "^5.2.0",
    "@angular/platform-browser": "^5.2.0",
    "@angular/platform-browser-dynamic": "^5.2.0",
    "@angular/router": "^5.2.0",
    "angular2-take-until-destroy": "^2.0.1",
    "core-js": "^2.4.1",
    "rxjs": "^5.5.6",
    "zone.js": "^0.8.19"
  },

Angular CLI: 1.7.3
Node: 8.9.4
OS: win32 x64
Angular: 5.2.9
... animations, common, compiler, compiler-cli, core, forms
... http, language-service, platform-browser
... platform-browser-dynamic, router

@angular/cli: 1.7.3
@angular-devkit/build-optimizer: 0.3.2
@angular-devkit/core: 0.3.2
@angular-devkit/schematics: 0.3.2
@ngtools/json-schema: 1.2.0
@ngtools/webpack: 1.10.2
@schematics/angular: 0.3.2
@schematics/package-update: 0.3.2
typescript: 2.5.3
webpack: 3.11.0

You must have left it by mistake:
https://github.com/NetanelBasal/ngx-take-until-destroy/blob/master/src/take-until-destroy.ts#L26

I would like to know if the component decorator @UntilDestroy() is inherited by a class that extends the AbstraceBaseComponent below:

@UntilDestroy( { checkProperties: true } )
@Component(
  {
    selector: 'pim-abstract',
    template: ``
  } )
export abstract class AbstractBaseComponent {
  @Input() maxChars: number
  currentIndex = -1

}

Is the @UntilDestroy() inherited by the ExtendedClass below?

export ExtendedClass extends AbstractBaseComponent {

}

Hi, would it be possible to create a whenDestroyed(this) function the same way we have a untilDestroyed?

Thanks Netanel
I would like to ask you which one I choose for my project in Angular 6?
1 - ngx-take-until-destroy
2 - ngx-auto-unsubscribe
ciao

Hello,

Big thumbs up for the plugin, thank you.

With the latest version, I get the following warning with "ng serve". I have not tested with AOT mode yet.

WARNING in ./node_modules/ngx-take-until-destroy/dist/umd/take-until-destory.js
13:24-31 Critical dependency: require function is used in a way in which dependencies cannot be statically extracted

On on app run, following error is thrown,

take-until-destory.js:13 Uncaught Error: Cannot find module "."
at webpackMissingModule (take-until-destory.js:13)
at eval (take-until-destory.js:13)
at eval (take-until-destory.js:19)
at Object../node_modules/ngx-take-until-destroy/dist/umd/take-until-destory.js (vendor.bundle.js:2762)

I am using RxJS version 5.5.6

Thanks.

Igor Minar tweeted the following a couple of weeks ago:

We strip only Angular metadata and decorators. That being said, we strongly discourage use of other custom decorators in Angular apps because they almost always cause payload deoptimizations and unused code retention (bigger bundles).

https://twitter.com/IgorMinar/status/1231026653385461760

Is performance a concern for this kind of usage?

I've just tested the example posted on the project page

ngOnInit() {
interval(1000)
.pipe(untilDestroyed(this))
.subscribe(val => console.log(val));
}

and it keeps on logging to console despite destroying the component.
I must point that on another v8 project this library works alright.

I installed the package in my project with
"npm install @ngneat/until-destroy"
I declared in my page
import { UntilDestroy, untilDestroyed } from '@ngneat/until-destroy';
@UntilDestroy()
export class myClass {
...
constructor(pServer: Servers) {
this.pServers.getServers().pipe(untilDestroyed(this)).subscribe((servers) => {
...

And then when I build I get these errors

Typescript Error
'=' expected.
node_modules/@ngneat/until-destroy/lib/internals.d.ts
export declare const DESTROY: unique symbol;
export declare function markAsDecorated(providerOrDef: InjectableType<unknown> | DirectiveDef<unknown> | ComponentDef<unknown>): void;

Please add type-safe of untilDestroyed or create new function something like 'untilComponentDestroyed'

export const untilComponentDestroyed = (componentInstance: OnDestroy) => untilDestroyed(componentInstance);

it's nice to use type checking right ?

I used the migration script (https://raw.githubusercontent.com/ngneat/until-destroy/master/migration/run.js) on my project.

Universally, UntilDestroy was added to the import statements.

However, only about 80% of the files had @UntilDestroy() added to the class/component declaration. I'm trying to figure out of the migration script missed these, or if they are not required.

My specific questions:

Is @UntilDestroy() required for EVERY @Component class that uses untilDestroyed(this) in the class? I have 4 @Components that the migration didn't decorate with @UntilDestroy()

Is @UntilDestroy() required for EVERY @Injectable class that uses untilDestroyed(this) in the class? I have 1 @Injectable that the migration didn't decorate with @UntilDestroy()

What about standard logic classes? I have 3 business logic classes that use untilDestroyed, but didn't get decorated with @UntilDestroy().

Is this the correct way:

@UntilDestroy()
class MyClass {
	constructor(obs: Observable<any>) {
		obs.pipe(untilDestroyed(this, 'destroy').subscribe(...);
	}

	destroy() { /* NO IMPLEMENTATION */ }
}

@Component...
class MyComponent implements OnDestroy {
	private myClass: MyClass;

	constructor() {
		this.myClass = new MyClass(obs);  // Source of obs not important.
	}

	ngOnDestroy() {
		if (this.myClass) {
			this.myClass.destroy();
			this.myClass = null;
		}
	}
}

Also, if possible, the original npm module should be marked as deprecated and have the readme updated with instructions to the new npm module.

Thanks in advance.

Edit:
What about @Directives? I found several @Directives that were not decorated. Do these also require @UntilDestroy()?

Netanel, first thank you so much for all of your work.

When exploring similar untilDestroyed implementations, one solution used a Symbol as the property key to guarantee the avoidance of property name conflicts.

Does it make sense to switch from a bare string to a Symbol to guarantee untilDestroyed only works with (and detects) properties managed by itself? I know it's a fairly safe assumption that a component or class wouldn't have a __takeUntilDestroy property, yet I'm a fan of 100% guarantees - are there any side effects that would come with using a Symbol?

Thanks!

"@angular/core": "9.0.2",
"rxjs": "6.5.4",
"@ngneat/until-destroy": "7.1.1",
"jasmine-core": "3.5.0",

On a component defined as

@UntilDestroy()
@Component({
  templateUrl: 'none-improvement.html',
  selector: 'cv-none-improvement-page',
  styleUrls: ['none-improvement.scss']
})
export class NoneImprovementPageComponent implements OnInit, OnDestroy {
  public firstName: string;

  constructor(
    private _user: UserProfileStore,
  ) {
  }

  public ngOnInit() {
    this._user.profile$
      .pipe(
        untilDestroyed(this)
      )
      .subscribe(u => this.firstName = u.get('firstName'));
  }

  public ngOnDestroy() {
    //
  }
}

I write this test:

  it('stops getting first name from user profile after destroy', () => {
    expect(sut.firstName).toBeUndefined();
    sut.ngOnInit();
    mockUserProfileStore.profileSubject$.next(new UserProfile(<any>{ firstName: 'testName' }).toImmutable());
    expect(sut.firstName).toEqual('testName');
    sut.ngOnDestroy();
    mockUserProfileStore.profileSubject$.next(new UserProfile(<any>{ firstName: 'newName' }).toImmutable());
    expect(sut.firstName).toEqual('testName');
  });

which fails. But if I use untilDestroyed(this, 'ngOnDestroy') passes. Is ngOnDestroy not the default method that triggers the unsubscription?

core.js:4002 ERROR Error: Uncaught (in promise): TypeError: Cannot read property 'onDestroy' of undefined
TypeError: Cannot read property 'onDestroy' of undefined
    at decorateDirective (ngneat-until-destroy.js:111)
    at ngneat-until-destroy.js:121

"@angular/core": "^8.2.2",

This is funny, but I have a very similar library that was originated from the times of angular 2 beta.

https://github.com/smnbbrv/ngx-rx-collector

And even the name of the pipe that I am using there is the same :)

Just wondering: why do you need a decorator? This is literally waste of code.

I don't want to import this on each class. So I've created a base class .

Will it work ( + AOT + Regular) if I declare this in a base class like this ?

notice : decorator is at base and also ngOnDestroy :

When unit-testing components decorated with @UntilDestroy this decorator has no effect since at present the JIT compiler is used for unit tests in Angular and not the AOT compiler. As a result the private properties that this decorator relies on don't exist on the components and our components behave differently under testing scenarios to real-life scenarios.

I note that in your unit tests, you do not use the real @Component annotation, but create the scenario that the AOT compiler uses. Having experimented with the code, I think it's possible to simply set properties directly on the target in the decorator in JIT mode to overcome this.

It's unclear from the Readme file whether untilDestroyed from @ngneat/until-destroy can be used with View Engine, or one must use the untilDestroyed from ngx-take-until-destroy.

Is @ngneat/until-destroy reserved for Ivy only?

If the answer is affirmative, then migrating to @ngneat dependency in case of View Engine wouldn't be possible for the time being.

In the README example for Use with any class it should be

pipe(
  untilDestroyed(this, 'destroy')
)

Currently it's

pipe(
 untilDestroyed(this),
 'destroy'
)

Unsubscribe doesn't work on Angular 9 but works on correct Angular 8

Same as 4.0.0, please get decorator TakeUntilDestroy back. It's very useful with not having a logic in components, which is generally a bad practice.

I've done migration from ngx-take-until-destroy to ngneat/until-destroy (after migration to angular packages in ver. 9.0.0). As application itself works fine, I've got issues with jest unit tests.

Error:
TypeError: Cannot read property 'onDestroy' of undefined

It's because you depend on target.ɵprov, but it doesn't have to be added by ivy compiler.

I am getting an error inside my components related to the library when i am running Storybook. Everything works fine when i use "ng serve".

Here is the error:

Uncaught TypeError: Cannot read property 'onDestroy' of undefined
    at decorateDirective (ngneat-until-destroy.js:111)
    at ngneat-until-destroy.js:121
    at __decorate (tslib.es6.js:56)

Here is my package.json

{
  "name": "",
  "version": "0.0.0",
  "scripts": {
    "ng": "ng",
    "start": "ng serve",
    "build": "ng build",
    "test": "ng test",
    "lint": "ng lint",
    "e2e": "ng e2e",
    "storybook": "start-storybook -p 6006",
    "build-storybook": "build-storybook"
  },
  "private": true,
  "dependencies": {
    "@angular/animations": "~9.1.0",
    "@angular/common": "~9.1.0",
    "@angular/compiler": "~9.1.0",
    "@angular/core": "~9.1.0",
    "@angular/forms": "~9.1.0",
    "@angular/localize": "^9.1.0",
    "@angular/platform-browser": "~9.1.0",
    "@angular/platform-browser-dynamic": "~9.1.0",
    "@angular/router": "~9.1.0",
    "@datorama/akita": "^4.22.0",
    "@ng-bootstrap/ng-bootstrap": "^6.0.2",
    "@ngneat/until-destroy": "^7.1.5",
    "bootstrap": "^4.4.1",
    "rxjs": "~6.5.4",
    "tslib": "^1.10.0",
    "zone.js": "~0.10.2"
  },
  "devDependencies": {
    "@angular-devkit/build-angular": "~0.901.0",
    "@angular/cli": "~9.1.0",
    "@angular/compiler-cli": "~9.1.0",
    "@angular/language-service": "~9.1.0",
    "@babel/core": "^7.9.0",
    "@datorama/akita-ng-router-store": "^3.1.3",
    "@datorama/akita-ngdevtools": "^3.0.2",
    "@storybook/addon-actions": "^5.3.18",
    "@storybook/addon-knobs": "^5.3.18",
    "@storybook/addon-links": "^5.3.18",
    "@storybook/addon-notes": "^5.3.18",
    "@storybook/addons": "^5.3.18",
    "@storybook/angular": "^5.3.18",
    "@types/jasmine": "~3.5.0",
    "@types/jasminewd2": "~2.0.3",
    "@types/node": "^12.11.1",
    "babel-loader": "^8.1.0",
    "codelyzer": "^5.1.2",
    "jasmine-core": "~3.5.0",
    "jasmine-spec-reporter": "~4.2.1",
    "karma": "~4.4.1",
    "karma-chrome-launcher": "~3.1.0",
    "karma-coverage-istanbul-reporter": "~2.1.0",
    "karma-jasmine": "~3.0.1",
    "karma-jasmine-html-reporter": "^1.4.2",
    "protractor": "~5.4.3",
    "ts-node": "~8.3.0",
    "tslint": "~6.1.0",
    "typescript": "~3.8.3"
  }
}

Might be relevant, i am not sure.
storybookjs/storybook#9876

In my project which employs Babel, Jest tests which passed before I started using your package are now failing with a message indicating that the code from your package is not plain JavaScript. In your package.json, the module field is set to "dist/es5/index.js", which I believe uses CommonJS modules, while main is set to "dist/index.js", which employs standard JavaScript modules. Reading this proposal describing how the module field allows opt-in use of standard JavaScript modules (while still providing access to CommonJS modules through main), I feel that these two field values should be switched. And indeed, when I switch them, my tests pass again.

If component A is inherited from Class B, subscriptions from component A are not unsubscribed when component is destroyed.

I could solve this by changing from
return (type as ComponentType).edir || (type as DirectiveType).ecmp;
to
return (type as ComponentType).ɵcmp || (type as DirectiveType).ɵdir;

I'm sorry for abusing the issues for a simple question. Maybe take this as a documentation request.
Is it correct that there is no way to use the operator without the decorator under Ivy?

Similar to existing issue #23.

For some components it works fine but randomly it throws this exception, probably something to do with Angular page cycle which keeps ngOnDestroy readonly till initialization is over. Tried to debug but couldn't figure out the root problem.

Appreciate any help. Thanks

I honestly dont know if im doing something wrong, but updating to the ivy version of this plugin, I find that when I add the @UntilDestroy() Decorator to my component, and reload that specific page, I get the following error in my console

ERROR Error: Uncaught (in promise): Error: The pipe 'translate' could not be found! Error: The pipe 'translate' could not be found!

Im using the latest version of ngx-translate .

The super wierd thing is, if i start my spa in a page with translations, but no observables/Until destroy, and the navigate to the page/component that uses @UntilDestroy() then there is no problem. But starting the spa on the page/component with both translation and @UntilDestroy(), creates the error, and breaks the component.

I really love this decorator. With version 3, I used readonly destroyed$: Observable<boolean> member passed to app logic-handling classes as an argument. Then takeUntil(destroyed$) took care of unsubscribing there. This way it's not necessary to pass the whole component to a method of other class.

In new version 4, @TakeUntilDestroy() and OnDestroy interface completely disappeared. Now passing the component class would make app-logic class dependent on a component type, which is not very handy. My point was to let a destroying component logic out of an app logic code as much as possible.

Would you consider to backport destroyed$ component observable into latest version, please? Perhaps as an another (optional) method for auto-unsubscribing.

Why you are not creating empty destroy fnction when function is nor provided? Instead of throwing an error

I have two components in lazy loaded modules where adding the decorator causes Angular-specific attributes, like *ngIf and mat-raised-button, not to be recognized on compilation.

Hi!

Just to let you know that the imports concerning rxjs (Observable, Subject,...) are not supported in the new version.

Can you create a release with the correct imports?

import { Observable, Subject } from 'rxjs';

I would be interesting for those starting a new project and not wanting to install the rxjs-compat package. And I'm usually using your lib to manage unsubscriptions 😋

Thanks in advance!! 👍

Hey!
Since this project does not use any angular components, would be nice to make it more universal. I have plan use it in React. :)

Then we could rename to 'rxjs-take-until-destroy' .

Example:

this.settingsService
      .get('darkMode')
      .pipe(untilDestroyed<App>(this, 'componentWillUnmount'))
      .subscribe((p: boolean): void => this.setState({ darkMode: p }));

Regards,
TheAifam5

With current custom destroy method implementation there are some issues

Playground for both cases here
https://ng-run.com/edit/LxkqzZQCoAv8i1KRl7Uj?open=app%2Fsome.service.ts

• having two destroy methods (for different streams) and calling one of them completes all other streams

  • press start
  • press start2
  • see two intervals in console
  • press either stop or stop2
  • both intervals complete (should complete only one)

• cannot use operator for start-stop case when you need to unsubscribe (after new subscriptions) multiple times during service lifetime

  (only first start/stop buttons now)

  • press start
  • press stop
  • press start again
  • press stop again
  • interval does not complete

It's real world use-cases from our apps where are a lot of such singleton services with start/stop methods for some pages business-logic.

As title suggests, have not had time to investigate further,

ngneat-until-destroy.js:51 Uncaught TypeError: Cannot read property 'onDestroy' of undefined
    at ngneat-until-destroy.js:51
    at __decorate (tslib.es6.js:56)
    at Module../src/app/layout/themes/default/shared/drop-selection/drop-selection.component.ts (drop-selection.component.ts:16)
    at __webpack_require__ (bootstrap:84)
    at Module../src/app/layout/core/core.module.ts (core.module.ts:1)
    at __webpack_require__ (bootstrap:84)
    at Module../src/app/layout/themes/default/layout.module.ts (layout.module.ts:1)
    at __webpack_require__ (bootstrap:84)
    at Module../src/app/app.module.ts (app.module.ts:1)
    at __webpack_require__ (bootstrap:84)

I suggest it's better to add condition to check if componentInstance['__takeUntilDestroy'] already exists.
But also put function with next/complete inside condition.
Because now, for example, if we call untilDestroyed(this) 4 times we get next chain:

componentInstance.ngOnDestroy --> componentInstance.ngOnDestroy --> componentInstance.ngOnDestroy --> componentInstance.__proto__.ngOnDestroy

With this code

if (!componentInstance['__takeUntilDestroy']) {
  componentInstance['__takeUntilDestroy'] = new Subject();

  componentInstance[destroyMethodName] = function() {
    isFunction(originalDestroy) && originalDestroy.apply(this, arguments);
    componentInstance['__takeUntilDestroy'].next(true);
    componentInstance['__takeUntilDestroy'].complete();
  };
}

we always get something like
componentInstance.ngOnDestroy --> componentInstance.__proto__.ngOnDestroy

It does not work for me. Not with the pipable syntax and not without. I used rxjs 5.5.10.
I used the @TakeUntilDestroy() and had an empty OnDestroy method.

Actual subscription:

constructor(private store: Store<fromAnnualWorks.State>) {
this.store.pipe(
takeUntil(this.destroyed$),
select(fromDocs.getRequestBelcotaxResponse))
.subscribe((res: RequestBelcotaxResponse) => {
this.processBelcoTaxResponse(res);
});
}

In Angular 6.1.0 changelog is reported this fix; angular/angular@fc03427
Seems to me that this should remove the need of explicitly specifying an empty ngDestroy.
Can you check if this is the case?

I have a (parent) class:

@TakeUntilDestroy()
@component({
selector: 'msp-toolbar-command-button',
templateUrl: './toolbar-command-button.component.html',
changeDetection: ChangeDetectionStrategy.OnPush,
})
export class ToolbarCommandButtonComponent implements OnInit, OnDestroy {

clicked$: Subject = new Subject()

readonly destroyed$: Observable

ngOnInit() {
this.clicked$
.pipe(takeUntil(this.destroyed$))
.subscribe((event: MouseEvent) => { ... })
}
ngOnDestroy() {
}
}

works as a charm.

And another class as its subclass :
@component({
selector: 'msp-toolbar-line-command-button',
templateUrl: '../toolbar-command-button/toolbar-command-button.component.html',
changeDetection: ChangeDetectionStrategy.OnPush,
})
export class ToolbarLineCommandButtonComponent extends ToolbarCommandButtonComponent {
}

Does an inherited class needs to be decorated as well?

I used UntilDestroy decorator and untilDestroyed rxjs operator in one component (only one component). It caused Wallaby.js extension (VS Code) to malfunction. Instead of throwing test fail error for a file, it simply malfunctioned for the entire project (malfunction: fails to detect 99% of the test files; doesn't run all tests even in those detected files).

Environment details:

Angular CLI: 9.0.1
Node: 12.6.0
OS: win32 x64

Angular: 9.0.0
... animations, cdk, common, compiler, compiler-cli, core, forms
... language-service, material, platform-browser
... platform-browser-dynamic, platform-server, router
Ivy Workspace: Yes

Package                            Version
------------------------------------------------------------
@angular-devkit/architect          0.900.1
@angular-devkit/build-angular      0.900.1
@angular-devkit/build-ng-packagr   0.900.3
@angular-devkit/build-optimizer    0.900.1
@angular-devkit/build-webpack      0.900.1
@angular-devkit/core               9.0.1
@angular-devkit/schematics         9.0.1
@angular/cli                       9.0.1
@angular/fire                      5.2.3
@angular/flex-layout               9.0.0-beta.29
@angular/service-worker            9.0.2
@ngtools/webpack                   9.0.1
@nguniversal/builders              9.0.0
@nguniversal/common                9.0.0
@nguniversal/express-engine        9.0.0
@schematics/angular                9.0.1
@schematics/update                 0.900.1
rxjs                               6.5.4
typescript                         3.7.5
webpack                            4.41.2

I use NX workspace with Jest.

Removing UntilDestroy and untilDestroyed from the component file fixes the issue. Keeping this library in node_modules doesn't affect Wallaby.js extension.

Hey there !

I had created the exact same operator for a projet I was hired on (before discovering your package), and we found out (the hard way) that you had to create at least the body of the ngOnDestroy method, even if it wasn't used.

I looked into it and it seemed to be an issue only in AOT compilation, but I've never really understood why. from a JS perspective only, creating the function in the decorator, even if it didn't exist, should not be an issue. Would you be able to explain it to me ?

Thank you in advance, and keep up the good work ! (By the way, I'm in love with Akita !)

When this library is used with your other library in the same component it generates an error because ngx-auto-unsubscribe unsubs the __takeUntilDestroy subject before it is able to emit its item to terminate the subscription it's attached to.

See console here https://stackblitz.com/edit/angular-3e29em?file=src%2Fapp%2Fapp.component.html

Adding pipe(untilDestroyed(this)) to all subscriptions made in our components makes some components to cause runtime errors.

Like this one:

Versions
@angular/*: 7.0.0
ngx-take-until-destroy: 5.2.3

From README:

Note: The decorator and operator should be used only with component or directive providers. Don't use it with application-level singletons (a.k.a. providedIn: 'root')

Can I ask why? When using live reload in development, untilDestroyed is equally useful. I'm using it all the time.

Hi,
I have an issue with this decorator on components. When it is used somewhere other than in ngOnInit or maybe before it, eg. constructor, the takeUntil under the hood does not work, subscription stays alive. This can be reproduced when you have eg. two routes and you switch between them.

Is this a known limitation? How can I prevent it?

Interestingly, when I use subject on cmp class and completing it in ngOnDestroy and I use it in takeUntil anywhere within the class (cmp) it works, it unsubscribes the subscriptions as opposed to untilDestroyed.

Thanks

Look at my code:

@TakeUntilDestroy()
@Component({/* somу code */})
export class PageMessageComponent implements OnInit, OnDestroy {
	public ngOnInit(): void {
		this.loadData();

		this.translateService.onLangChange.subscribe(() => {
			// here I want remove subscriptions and in loadData create them again
			this.loadData();
		});
	}

	public ngOnDestroy(): void {
		this.appService.setPageCode('');
	}

	private loadData(): void {
		this.newsService.getItems()
			.pipe(untilDestroyed(this))
			.subscribe(news => {
				this.news = news;
				this.isLoaded = true;
			});
	}

My question is: how is best way to destroy all subscriptions in onLangChange and run them again? Because after language change I need load another data for current component.

Maybe I can run this.ngOnDestroy(); - it's normal?