Somehow warn developers about erring or completing @Effect Observables

[michahell]

I think it is under-documented that, because @Effects are also Observables, they stop emitting values after erring or being completed.
I see waiting for something that never happens effectively as silently failing. As this happens more often when working with Observables, developers are used to it, but it could be expected that @Effects work differently.

It would be quite helpful to have a list of operators which are dangerous to use in @Effects, ie, operators that complete observables, such as first() and empty(), and using the catchError() operator in the 'main' Effect observable (as opposed to within switchMap, concatMap, map etc).

I suggest that either:

• @Effects when they error ór complete, provide a warning regarding them being completed.
• documentation is updated to reflect that developers have to be careful with certain operators (see list idea above) in @Effects.

related SO posts:

• https://stackoverflow.com/questions/44180361/ngrx-effect-does-not-run-the-second-time
• https://stackoverflow.com/questions/45523127/observable-with-rx-broken-after-error
• https://stackoverflow.com/questions/47896171/is-it-possible-to-throw-errors-inside-ngrx-effects-without-completing-the-observ
• https://stackoverflow.com/questions/45556674/ngrx-effect-only-triggers-once-angular-4

[timdeschryver]

I believe #1224 would help here.

I think explaining the different (dangerous) operators inside the NgRx docs is not the right place. Perhaps we should add a catchError example and explicitly mention it, or add it to a "FAQ" section?

[michahell]

Yes, showing how to handle errors in an Effect would be a great start, or better said, how not to handle errors :)
I dont fully grok the safeCall operator yet, but it looks like the purpose is an operator with two end phases, either success or erring, which I think is the 99% use case indeed :)

[timdeschryver]

I'll close this issue in favor of #1336 .