These are great patterns and also make the effects way easier to test! The only thing I'm not sure about only dispatching one action per effect. Like if, on a success action, want to update state, show a notification and route to a new page, it seems like it would be duplicate code to have three separate effects that listen for the same action. And you might want those actions dispatched in a particular order.
I would argue that the notification and route navigation are commands, and should be performed thru an injected service. As to the particular order, that would be easy as you could do SuccessAction -> showNotification$ -> NotificationDisplayed -> redirectToNewPage$.
Of course, the user might miss that notification if you're immediately redirecting, so hopefully there's a delay in there (which would be easier to do with distinct effects as opposed to them all immediately emitting at once from a single effect).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
These are great patterns and also make the effects way easier to test! The only thing I'm not sure about only dispatching one action per effect. Like if, on a success action, want to update state, show a notification and route to a new page, it seems like it would be duplicate code to have three separate effects that listen for the same action. And you might want those actions dispatched in a particular order.
I would argue that the notification and route navigation are commands, and should be performed thru an injected service. As to the particular order, that would be easy as you could do SuccessAction -> showNotification$ -> NotificationDisplayed -> redirectToNewPage$.
Of course, the user might miss that notification if you're immediately redirecting, so hopefully there's a delay in there (which would be easier to do with distinct effects as opposed to them all immediately emitting at once from a single effect).