CANCELED, think of it as a finite state machine.
ActionContext, that has 2 properties:
DISPATCHEDstatus and invokes the appropriate handlers for this action. After all processing for the action has completed it generates a new
ActionContextwith the following
dispatchmethod is then triggered after the action is handled "successfully" and, in response to this observable, you are able to do the actions you wanted to do on completion of the action.
GetNovelshandler throws an error, for example:
ActionContextwill be created:
CANCELEDstatus? Only asynchronous actions can be canceled, this means that the new action was dispatched before the previous action handler finished doing some asynchronous job. Canceling actions can be achieved by providing options to the
GetNovelsaction on click:
switchMap. If we didn't use NGXS - the code would look as follows:
GetDetectivesactions separately like this:
GetNovelswould be dispatched before
GetDetectives. This is true due to the synchronous nature of the dispatch, but their action handlers are asynchronous so you can't be sure which HTTP response would return first. In this example we dispatch the
GetDetectives, but if the call to fetch novels takes longer then the
novelsproperty will be set after
store.dispatchfunction returns an observable that can be used to respond to the completion of each of these actions.
store.dispatchfunction that will fire only when both actions have completed. The below diagram demonstrates how asynchronous actions are handled under the hood:
onErrorobservable callback and neither the
onCompletecallbacks would be called.
@Actionmethod that represents that asynchronous work (and completion). The completion of the action will then be bound to the completion of the asynchronous work. If you use the
asyncmethod returns the
Promisefor you. If you return an
ObservableNGXS will subscribe to the observable for you and bind the action's completion lifecycle event to the completion of the
@Actionmethod. Note that in the case of an
Observableyou would have to
.toPromise()to ensure that your observable runs.
GetNovelsaction to wait for the detectives to load then we would have the following code:
GetDetectivesaction would be dispatched just before the
GetNovelsaction completes. The
GetDetectivesaction is just a "fire and forget" as far as the
GetNovelsaction is concerned. To be clear, NGXS will wait for a response from the
getNovelsservice call, then it will populate a new state with the returned novels, then it will dispatch the new
GetDetectivesaction (which kicks off another asynchronous request), and then
GetNovelswould move into its' success state (without waiting for the completion of the
GetNovelsaction to wait for the
GetDetectivesaction to complete, you will have to use
mergeMapoperator (or any operator that maps to the inner
exhaustMap) so that the
Observablereturned by the
@Actionmethod has bound its completion to the inner action's completion:
async/awaitsyntax. The same method would be as follows:
awaitkeyword here would cause this to be "fire and forget" again.
DISPATCHED. Next, NGXS looks for handlers that listen to this action, if there are any — NGXS invokes them and processes the return value and errors. If the handler has done some work and has not thrown an error, the status of the action changes to
SUCCESSFUL. If something went wrong while processing the action (for example, if the server returned an error) then the status of the action changes to
ERRORED. And if an action handler is marked as
cancelUncompletedand a new action has arrived before the old one was processed then NGXS interrupts the processing of the first action and sets the action status to