Ok, the way I see it, to show a spinner or not is part of the application state and therefore it is perfectly viable to have an isLoading boolean in the store. So I would use the effects and store as you describe, but also involve isLoading as store state. That boolean (or a more specific version of that, like isTalksLoading) can then drive either the spinner (an app-wide visual clue) OR (impossible with Savkin’s impure reducer) a component specific visual clue (like a spinner placed in situ of a component to show, or Philips specific loading message, e.g. ‘loading talks…’, or a skeleton component). To achieve that the component should be redirected to *synchronously*, hence:

• not guarded (by a condition that becomes asynchonously true)
• not delayed by a resolver

which makes the entire approach actually *simpler*.

Instead, that component’s template should just have two xor-ed html structures, one for the ‘isLoading’ case, and one for the ‘actual’ case, both controlled by an *ngIf of the async piped store.isLoading.

Does that make sense to you?