3

The sample apps for ngxs typically dispatch discrete success / failed actions for every asynchronous action.

For example: https://github.com/tommythongnguyen/Ngxs-Pizza-Order/blob/master/src/app/products/store/pizzas.state.ts#L45

To me it makes more sense to simply observe the dispatch, if you want to wait for an action to succeed/fail.

For most cases, you would only care about failure, as to read the data back out of the store, I'd be expect to be using independent selects rather than looking at the action stream.

In terms of handling failure, I think that normally it would be the dispatcher who would be interested in handling a failure.

Stackblitz showing my preferred approach: https://stackblitz.com/edit/angular-ngxs-so-question

Is this pattern just a hold over from flux / redux where the dispatches don't return a handle on an async action? Or is some benefit to this approach that I'm not seeing?

Michael
  • 2,189
  • 16
  • 23
  • 1
    Not an answer becouse i am not sure about it: in CQRS pattern (see ngxs.io frontpage - maybe i am wrong, but ngxs is cqrs) Command (`@Action()`) should return void ("pure cqrs as in spec") but in reallity ("battle tested cqrs") it is practical to return at least "everything goes (well / to hell)" (see https://stackoverflow.com/questions/43433318/cqrs-command-return-values). And i *think* you just switched from "pure cqrs" (with success/failed Command/`@Action()`) to "battle tested cqrs") – Jan 'splite' K. Jun 09 '20 at 11:22

1 Answers1

1

In my experience with NGXS so far, we've used both your preferred approach, and in some cases explicit success/failure actions.

Where we used explicit actions was typically where we had one state wanting to respond to the change in another.

E.g. having a state that capture some common reference data, but we can only load that after the user has logged in. We dispatch a LoginSuccess action, and have the ReferenceDataState respond to that to call the API and fetch reference data.

Another case we have is that the caller wants to know some data e.g an ID of an entity created by the originating action. Store's dispatch function returns an Observable with void return type, so we can use a success action to pick up that result value.

Garth Mason
  • 7,611
  • 3
  • 30
  • 39
  • What do you mean by `Store's dispatch function has a void return type`? When I look at the source, it looks like it has `Observable` type (https://github.com/ngxs/store/blob/0fbf2fb1339d87c484cdfb30d5b4012ef1e6298d/packages/store/src/internal/dispatcher.ts#L38). – Dzhavat Ushev Jan 31 '19 at 10:26
  • I was referring to the documentation re: dispatching actions [here](https://ngxs.gitbook.io/ngxs/concepts/store) - meant an Observable of void type. I hadn't checked the source for a while is the documentation not aligned with the latest release? – Garth Mason Jan 31 '19 at 12:48
  • It looks like there's something going on (or maybe I don't fully understand how it works). When I `subscribe` to `dispatch` what I get back is the state at that particular moment (`.subscribe(value => console.log(this.store.snapshot() === value)` gives `true`). Obviously, if more actions are dispatched, then the returned value might be an old form of the state but there's a return value nonetheless. It will be interesting to learn more. – Dzhavat Ushev Jan 31 '19 at 13:26
  • That signature might have changed, I'm not running the very latest version of NGXS in our app - I'll take a closer look when we upgrade. – Garth Mason Feb 01 '19 at 01:16