[feat] slight different takeUntilDestroy pattern about ngxtension-platform

[eneajaho]

@dmorosinotto
I wouldn't call it noise, it's constructive discussion (so thank you for all the feedback) that other devs can read and learn more about different ways of doing things and using what they like.

injectDestroy has existed for some time before coming in ngxtension.

Here are two more tweets about it that may be interesting to other people:

• https://twitter.com/Enea_Jahollari/status/1691571381215936751
• https://twitter.com/Enea_Jahollari/status/1630665586245242881

I'm closing this issue, but the discussion can continue!

[dmorosinotto]

Yes I know and use the "destory$" pattern from years, and even mine BaseComponent in many personal project, but with the new inject FOMO from NG14+ I slight change it, to finally arrive where we are now with the implementation of the takeUntilDestoryed done by the Angular guys, finally solving this problem for all of us without need of our "poor dev" custom solutions 😜

Thanks to all of you for the constructive discussion!
I'll go to dedicate some times to other issues I've opened, but right now I need a little ☕ and rest because today was a full-intense day 😉

[nartc]

@dmorosinotto I think we're looking at things from a different point of view here. I don't think we should always tie a destroy$ subject to just takeUntil. There are different use-cases where a notification of when a component's destroyed would be beneficial. For example an AlertComponent that can be closed by 3 different ways:

• The user clicks on "X" explicitly
• After 5 seconds
• The parent component is destroyed

merge(closeClick$, timer(5000), destroy$)
    .pipe(take(1))
    .subscribe(() => {
        // some logic to close Alert
    });

Assuming you type everything out and don't use auto-import, "keystroke save" would not be a valid argument since injectTakeUntilDestroy() would contain more characters.

[nartc]

How about exposing a base DestroyableComponent with takeUntilDestroy from ngxtension/inject-destroy entry point?

[dmorosinotto]

I rarely use the destory$ subject in my component, for me it is just an "implementation detail" to have the takeUntilDestory operator, if you take a look of my initial base.component and the new injectTakeUntilDestory fn at the end my final scope is to add a "custom operator" scoped to the component to easily use the .pipe(...., takeUntilDestory() ) without any parameter o "Subject signal" but maybe I'm missing something and you really need the destroy$ in some cases

[nartc]

I assumed that you'd want something to replace BaseComponent so that you wouldn't have to change a lot of downstream code.

I suggested that we add a DestroyableComponent to ngxtension/inject-destroy entry point (i.e: import { DestroyableComponent } from 'ngxtension/inject-destroy')

Or BaseComponent can be rewritten as follow:

import { Directive } from "@angular/core";
import { takeUntil } from 'rxjs';
import { injectDestroy } from 'ngxtension/inject-destroy';

@Directive() // Needed only for Angular v9+ strict mode that enforce decorator to enable Component inheritance
export abstract class BaseComponent {
  private destroy$ = injectDestroy();
  protected takeUntilDestroy = () => {
    return takeUntil(this.destroy$);
  }
}

One thing you can also improve is to make injectDestroy() creates the underlying destroy$ Subject lazily.

[dmorosinotto]

I mostly refactor my code using the injectTakeUntilDestroy
I keep my BaseComponent just for "historical reason" (aka not break/refactor all my components), but this is my project concern, maybe for a utils lib like yours the pattern more useful to expose is injectTakeUntilDestroy helper fn, not a DestoybleComponent that may become a constraint dependency in the future...
If someone want a BaseComponent (as I have done) can easily build and name it as they wish and get the takeUntil "behaviour" using the injectTakeUntilDestroy helper fn naming the operator as they wish.

@Directive()
abstract class MyBaseDestoyableWhatever {  // YOU CHOOSE THE NAME OF THE BASE CLASS TO MINIMIZE REFACOR
    protected untilExit = injectTakeUntilDestroy; // AND THE NAME OF YOUR "CUSTOM OPERATOR" -> takeUntil(destroy$)
}

@Component(...)
class MyComp extends MyBaseDestoyableWhatever {
     public obs$ = inject(SomeService).getData$.pipe(..., this.untilExit() );  //SAMPLE USING IT IN DERIVED COMPONENT
}

I'm NOT suggestion to remove your injectDestroy fn, just eventually add the injectTakeUntilDestroy (ignore the console.info 😉)

[nartc]

I see. If that's the case, I don't think injectTakeUntilDestroy provides any apparent value in addition to injectDestroy

export class SomeComponent {
    destroy$ = injectDestroy();

    ngOnInit() {
        interval(1000).pipe(takeUntil(this.destroy$));
    }
}

// versus
export class SomeComponent {
    takeUntilDestroy = injectTakeUntilDestroy();

    ngOnInit() {
        interval(1000).pipe(this.takeUntilDestroy());
    }
}

[majies]

Not sure if I'm 100% following this correctly, but does all this get fixed by angular takeUntilDestory (currently dev preview) from rxjs-interop which will emit on current destory injection context or you can pass in your own reference

https://angular.io/api/core/rxjs-interop/takeUntilDestroyed

[nartc]

I'm pretty sure @eneajaho has an explanation for injectDestroy.

[eneajaho]

yeah just left a comment here: https://twitter.com/Enea_Jahollari/status/1702346249855197491

[dmorosinotto]

@nartc the value added from my implementation is that using it you don't need 2 import to make it work, because you don't need to import { takeUntil } from "rxjs" , just some keystroke saved ;-)

@eneajaho responded in the Twitter/X thread

@majies You are totally right, looked inside the "official" Angular implementation, at the end is quite similar to mine, I use a Subject, they created a lightway Observable that next/complete onDestroy, so the Angular code is even better than mine, and I can totally see a way to refactor my BaseComponent class using it.

So if all you agree, I can close this Issue because it can be solved without implementing a new method in ngxtension (less code to manintain for everyone), and just keeeping the actual injectDestory implementation as-is for those who prefer having a "Subject signaling" when the component (or service) is destroied ;-)

Sorry to the noise caused, and thanks for all you feedback and comments to get a final solution to my needs

[dmorosinotto]

Yes @nartc you are right, I use the "keystroke saving" just to say don't have to use a double dependency and hide it in an "internal detail" of the ngxtension implementation, and totally agree that injectDestroy may be useful in other use-cases different to the takeUntil, what I may suggest is that if I'll need to use it just to takeUntil-pattern probably I'll go to the "official" Angular takeUntilDestoryed just to have an all-in-one "behavior" but this is just my personal preference 😉