Handling a spinner for multiple REST calls
It is in theory not necessary to unsubscribe all subscriptions. For example if you call the backend with the Angular HttpClient then you will get an observable, that will automaticly complete after it emits the first result. As soon as it is completed, the observable is gone and does not strain your ressources anymore.
That means, if the Observable will complete itself in a timely manner, then you do not have to unsubscribe.
BUT: In most cases you have to dig a bit deeper to see that an observable will complete itself. That means the reader of your code will not easily know if you forgot the unsubscribe or if it could be skipped. Therefore i personaly decided for safety (but more code) and unsubscribe always.
Not unsubscribing will result in unnecessary memory consumption and/or can create unexpected sideeffects. The function that should be executed at emits, is stored at the Subject. That means even when your component is long ago destroyed, the function will still &quot;live&quot; at the Subject. And will be executed at each emit...
But you could make unsubscribing a bit nicer with a Subscription Object
private subscriptions: Subscription = new Subscription();
...
this.subscriptions.add( myOberservable.subscribe(value =&gt; doMagic(value)) );
this.subscriptions.add( myOtherOberservable.subscribe(value =&gt; doMoreMagic(value)) );
...
this.subscriptions.unsubribe() // will unsubscribe all added subscriptions at once

About the general question of implementing the spinner. If you always want a spinner, you could attach it in an interceptor, activating the spinner before the call is fired and deactivated as soon as you get a respond.
Or using a central method for backend calls and doing the the toggle there.
In both cases you would need a spinner service that needs to remember how often it was &quot;activated&quot;, so that if 3 calls are triggered at once, the first response does not deactivate the trigger.
May ways are possible, it depends a bit on your use case and your general architecture.
But your specific example i would write in the following way:
export class MyComponent implements OnInit, OnDestroy {

  private subscriptions: Subscription = new Subscription();
  private filterLoading$:BehaviorSubject&lt;boolean&gt; = new BehaviorSubject&lt;boolean&gt;(true);

  ngOnInit(){
      this.subscriptions.add(this.callAll().subscribe(() =&gt; this.toggleSpinner()));
  }

  ngOnDestroy(){
      this.subscriptions.unsubscribe();
  }
  
  private callAll():Observable[]{
    const listOfCalls: Observable[] = [
          remoteService.getFirst(),
          remoteService.getSecond(),
          remoteService.getThird(),
    ];
    return forkJoin(listOfCalls);
  }

  private toggleSpinner():void{
      this.filterLoading.next(false)
  }
}

Its nearly the same way you used. Only a few changes.

If there is no need to declare something public, then its private.
I make use of the &quot;Subscription&quot; Object, even if in this example there is just one subscription to be stored. I try to be consisten with solutions. Also it makes it easier to extend the component when a second subscription is needed.
I like to hide code behind methods. That way someone reads the methodname and then can decide if he/she is interested in the details or not.

All in all its more code. But i think its easier to understand. And in my experience, code is read quite more often then writen. And &quot;read&quot; really means &quot;reading and understanding&quot;. And thats an very expensive task. :-)
As always, the solution totaly depends on the context. So, choose the things that suit you well and skip the rest. :-)