takeUntilDestroy in Angular v16

[MaciejWWojcik]

Discussion about the article "takeUntilDestroy in Angular v16". Enjoy! 🥳

[DmitriyIvanko]

If you look at the following code, then when the component is destroyed, the second subscription will exist. I just can't understand why and how to make the code work for any number of subscriptions in the component? Perhaps I misunderstood something?

import { takeUntilDestroyed } from '@angular/core/rxjs-interop'

  constructor(
  ) {
    interval(1000).pipe(
      takeUntilDestroyed(),
    ).subscribe(console.log)

    interval(1000).pipe(
      takeUntilDestroyed(),
    ).subscribe(console.log)
  }

Already answered in StackOverflow (https://stackoverflow.com/questions/76279303/angular-16-takeuntildestroyed-operator-with-two-subscribe-methods)Thanks

[MaciejWWojcik]

cool, good to know! so basically the Angular v16.0.2 is the way to go 🤓

[mhombach]

Hey. For some odd reason I can't use takeUntilDestroyed without explicitly passing a destroyRef...
With

interval(500)
  .pipe(takeUntilDestroyed())
  .subscribe((count) => console.log(count));

I receive

core.service.ts:26 ERROR Error: NG0203: takeUntilDestroyed() can only be used within an injection context such as
a constructor, a factory function, a field initializer, or a function used with `runInInjectionContext`.
Find more at https://angular.io/errors/NG0203

Am I missing something or is this a bug in my Angular 16.1.0?

[MaciejWWojcik]

yup, never tested the functions called from the constructor but I would expect that to work

[mhombach]

Got it now, with the support of some videos :) My feedback to this already great article would be that it should maybe mention this small but important fact. Usually, I guess, we devs will be subscribing to things not in the constructor but the ngOnInit. So it's good to know that, for very Angular internal reasons, the constructor is different here than some other lifecycle-hook.
And I double-checked, yes it also works in methods called from inside the constructor :)

[MaciejWWojcik]

cool, thanks mate!

[juanmendes]

@MaciejWWojcik I agree but isn't the message very clear?

[MaciejWWojcik]

I think the "injection context" is just something that becomes popular because of new features that are using it and we need to learn that. Once the injection context as a concept is clear, then the error message makes sense.

When I say new features - I mean the inject function, or this new operator. I expect in the future the injection context will be commonly used.