1

I have an actions file like this:

export enum ActionTypes {
  FailureAction = 'Failure action',
}

export class FailureAction implements Action {
  readonly type = ActionTypes.FailureAction;

  constructor(public payload: any) { }
}

export type ActionTypes = FailureAction;

I want to add some logic in the FailureAction class so that whenever this action gets called, we call a service that decides how to show an error (the only parameter is a code). I created a class that has the code parameter in the constructor and uses a dependency injector defined in the app module (Inject a service manually) to get the service needed. Then I extended the FailureAction with the newly made class and called super() with the code parameter in the constructor. When I dispatch the FailureAction the console gets bombarded with errors and crashes the whole application.

errors

Is this even doable the way I'm trying to do it? Any alternative suggestions?

Phaze
  • 545
  • 1
  • 5
  • 14
  • 2
    Pretty unclear what you’re trying to do.. but piggybacking anything inside an action is probably a bad idea to start with. If you need anything done when an Action is fired, you should probably just use an Effect for that..? – MikeOne Oct 22 '20 at 18:43
  • I'm working on a big project that has a huge variety of different possible errors. Currently, the solution is to have an effect for it but the problem with that is that there's a lot of boilerplate and it's quite messy to maintain. So I'm just trying to find a better way to handle it if it's possible. – Phaze Oct 22 '20 at 19:27
  • Maybe you could have a dictionary somewhere that maps error codes (key) to e.g. the respective handling service (value). Then just have the services (un)register themselves. Then an effect that listens to the failure action can invoke the service with the given error code (+ adding a fallback if there is no matching key for a code). – Gunnar B. Oct 22 '20 at 19:32
  • Understood. There are different options.. you could introduce a simple service instead of going the direct NgRx route. Just listen to the ActionsSubject and filter out what you need? – MikeOne Oct 22 '20 at 19:33
  • Yeah, Mike is correct. You definitely want to consider "is Ngrx going to help me solve this problem". My assumption is no, in my experience it often creates more overhead than needed. – marcusshep Oct 22 '20 at 20:31

1 Answers1

1

Action classes should not have special logic in them. The action is just a data payload that is getting passed around through the framework.

There are two ways (that I know of offhand) to handle actions:

  1. A Reducer function uses an Action and a State to produce another State
  2. An Effect listens for an Action, performs some side-effect operation, then produces a different Action

If you need to perform some operation based on an action (for example, looking up data from the server or local storage), you could use an Effect. You might have a flow that looks something like this:

Error happens -> dispatch new error action (error code)

Error action -> Error handling effect (look up error code) -> new error message loaded action

Error message loaded action -> error view reducer -> new view state with error message

Effects are injectable services, which may reference and use other services.

Have a look at the documentation for @ngrx/effects: https://ngrx.io/guide/effects

RMorrisey
  • 7,637
  • 9
  • 53
  • 71