Why must must ngrx / redux effects return actions? Is using a noop action like elm considered bad practice?

Eeks33 picture Eeks33 · May 18, 2017 · Viewed 8.8k times · Source

I'm using a redux-style state management design with Angular and ngrx/store and ngrx/effects. Whenever I don't return an action from an effect, I get an error:

Cannot read property 'type' of undefined

I researched the issue and found that in an elm architecture there is something called a "noop" action that does nothing that you can call when you don't want to chain another action with your effect. Calling this noop action everywhere seems extremely repetitive to me. I am wondering if this would be a bad practice to follow. Is there a reason you cannot have an effect that does not return an action? Is the intention of effects to always have 1 action fire another action? I'm wondering if I am misunderstanding how to use effects.

Thanks!

Answer

mtx picture mtx · May 18, 2017

By default, an ngrx/effect dispatches an action.

If you want an effect to be 'fire-and-forget', all you need to do is add {dispatch: false} as an argument to the @Effects() decorator.

From the @ngrx/effects docs:

Observables decorated with the @Effect() decorator are expected to be a stream of actions to be dispatched. Pass { dispatch: false } to the decorator to prevent actions from being dispatched.

Usage:

class MyEffects {
  constructor(private actions$: Actions) { }

  @Effect({ dispatch: false }) logActions$ = this.actions$
    .do(action => {
      console.log(action);
    });
}

Under the hood, this is achieved with the ignoreElements operator. (Here is the source-code of ngrx/effects if you are interested). ignoreElements has a built in noop function that gets called every time the effect runs.

In short, there is no need for an explicit noop-action in ngrx/effects. I wouldn't outright call it 'bad practice' to dispatch a noop-action, but it is certainly not necessary when using ngrx.