SF-3532 Dispose realtime docs when no longer in use

[Nateowami]

This is still work in progress, but I want to put it out here as it appears to be working.

---

This change is 

---

[codecov]

Codecov Report

❌ Patch coverage is 68.95833% with 149 lines in your changes missing coverage. Please review.
✅ Project coverage is 81.02%. Comparing base (4dfaf94) to head (ea6c2bf).
⚠️ Report is 1 commits behind head on master.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
...boarding-requests/onboarding-requests.component.ts	0.00%	32 Missing ⚠️
...re/ClientApp/src/xforge-common/realtime.service.ts	63.79%	21 Missing ⚠️
...diagnostic-overlay/diagnostic-overlay.component.ts	0.00%	14 Missing ⚠️
...nx-insights-panel/lynx-insights-panel.component.ts	7.69%	12 Missing ⚠️
...e/ClientApp/src/app/shared/project-router.guard.ts	56.52%	10 Missing ⚠️
...uest-detail/onboarding-request-detail.component.ts	36.36%	7 Missing ⚠️
...App/src/xforge-common/activated-project.service.ts	76.66%	7 Missing ⚠️
...ure/ClientApp/src/xforge-common/project.service.ts	22.22%	7 Missing ⚠️
...al-administration/serval-administration.service.ts	25.00%	6 Missing ⚠️
...pture/ClientApp/src/app/core/sf-project.service.ts	78.94%	4 Missing ⚠️
... and 17 more

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3199      +/-   ##
==========================================
- Coverage   81.03%   81.02%   -0.02%     
==========================================
  Files         645      646       +1     
  Lines       41523    41741     +218     
  Branches     6758     6787      +29     
==========================================
+ Hits        33650    33819     +169     
- Misses       6761     6807      +46     
- Partials     1112     1115       +3     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

[marksvc]

Hello @Nateowami ,

Thank you for your work on this!

Here are some comments on the code.

I find positive names to be easier to understand than negative names, when using boolean logic. I suggest to consider renaming DocSubscription.isUnsubscribed$ to isSubscribed$.

Can you explain more about the use of DocSubscription.unsubscribe() instead of using a destroyRef argument to DocSubscription.constructor? It looks like DestroyRef is for some angular classes, and so if we want to use a DocSubscription in a different situation, we might not have a DestroyRef available, and so we would use DocSubscription.unsubscribe?

Rather than provide DocSubscription.unsubscribe for situations where a DestroyRef|Observable was not provided to DocSubscription.constructor, do you think we could always require clients to do one of

• Give a DestroyRef that they have.
• inject a DestroyRef, and pass it to DocSubscription.constructor, and later the DestroyRef gets destroyed when.. when the "corresponding injector is destroyed"; or
• Pass an Observable, and emit from the Observable when the client wants to unsubscribe.
  I'm thinking this would reduce the complexity and variation of the DocSubscription class. (DocSubscription.unsubscribe could be removed.)
  I might have to have a look at what that looks like to decide if I like it better or worse :).

It looks like if we removed DocSubscription.unsubscribe, and instead had clients pass an Observable, that might look something like

// New client field
private readonly bye$ = new Subject<void>();
...
// Pass in constructor
new DocSubscription('DraftGenerationStepsComponent', this.bye$.asObservable())
...
// New client method
wave(): void {
  this.bye$.next();
  this.bye$.complete();
}

I want to mention that we could further reduce the complexity of DocSubscription by changing the constructor destroyRef argument from DestroyRef | Observable<void> to just Observable<void>. That would give some simplification.
Client code might change from

new DocSubscription('DraftGenerationStepsComponent', this.destroyRef)

to something like

new DocSubscription('DraftGenerationStepsComponent', new Observable(subscriber => this.destroyRef.onDestroy(() => subscriber.next())))

That makes the client code more complex just to simplify DocSubscription.constructor by a couple lines, so I'm not too inclined toward it. But I wanted to mention that idea in case it inspires other ideas.

Sometimes when working in TypeScript it seems like it could be useful to have a standard disposable system. In C#, there is an IDisposable interface, and implementing classes have a dispose() method that is called when the class is going away. In this dispose method you can let go of resources that you were holding onto.
If we had any desire to apply a generic disposal system across the frontend TypeScript application, this might be a good place to implement and do it.
AI suggested some disposal patterns that could be applied, which are

• Implement our own Disposable interface with a dispose method like C#.
• Using RxJS Subscription, where we add in each held resource and then in ngOnDestroy or another "dispose" method we let go of the resources.
• Using Angular DestroyRef. I wonder if we can use this with arbitrary classes, not just with Components and Directives.
• And of interest, in the future, using might come to TypeScript.

In C#, the IDisposal.dispose method is automatically called if you are using an object and it goes out of scope. (using someResource = foo()) Unfortunately, only the Angular DestroyRef and in-the-future using patterns above would be as automated (at least where we could not rely on ngOnDestroy). Hmm.
Well, do you have any comments on generic disposal ability in the frontend application?