DEV Community

Discussion on: 3 Radically Small Things You Can Change In Your NgRx Effects Code 🌞

Collapse
 
davidshortman profile image
David • Edited

We may disagree, but in my view effects are not event handlers. Effects are intended to provide a way to invoke side effects for a potential array of events and other Observable streams in the system.

If they were event handlers, then I would prescribe each effect have only one way to be triggered. And further, an event can trigger many things to occur, and therefore effects would have many results.

But then we lose the flexibility and composability of effects.

To stick with the event handler view of effects means you would need to have a duplicate effect for each event that should trigger a form save, for example. Now, you could have each event-handler-effect call some save private function, but that duplication is unneeded since we can write simpler Observable streams to react to the stream of Actions using the variatic ofType operator.

Thinking about (and naming) effects as a true "side-effect" in a system means thinking of units of side effects that can be triggered. The beautiful thing about NgRx Effects using RxJs Observables also means something else pretty important about effects- they don't just have to be triggered by actions. Effects can be written to react to any Observable stream, which means you can write some pretty powerful and elegant triggers for very simple results.

TLDR- naming effects as event handlers leads to writing effects that are not flexible or easily composable (in this writer's opinion)