Using DataPersistence

Managing state is a hard problem. We need to coordinate multiple backends, web workers, and UI components, all of which update the state concurrently.

What should we store in memory and what in the URL? What about the local UI state? How do we synchronize the persistent state, the URL, and the state on the server? All these questions have to be answered when designing the state management of our applications. Nx provides a set of helper functions that enables the developer to manage state in Angular with an intentional synchronization strategy and handle error state. Check out the Managing State in Angular Applications using NgRx for more detailed example of the state problem Nx is solving.

Optimistic Updates

For a better user experience, the optimisticUpdate operator updates the state on the client application first, before updating the data on the server-side. While it addresses fetching data in order, removing the race conditions and handling error, it is optimistic about not failing to update the server. In case of a failure, when using optimisticUpdate, the local state on the client is already updated. The developer must provide an undo action to restore the previous state to keep it consistent with the server state. The error handling must be done in the callback, or by means of the undo action.

1import { Actions, createEffect, ofType } from '@ngrx/effects';
2import { optimisticUpdate } from '@nrwl/angular';
3
4@Injectable()
5class TodoEffects {
6  updateTodo$ = createEffect(() =>
7    this.actions$.pipe(
8      ofType('UPDATE_TODO'),
9      optimisticUpdate({
10        // provides an action
11        run: (action: UpdateTodo) => {
12          return this.backend.updateTodo(action.todo.id, action.todo).pipe(
13            mapTo({
14              type: 'UPDATE_TODO_SUCCESS',
15            })
16          );
17        },
18        undoAction: (action: UpdateTodo, error: any) => {
19          // dispatch an undo action to undo the changes in the client state
20          return {
21            type: 'UNDO_TODO_UPDATE',
22            todo: action.todo,
23          };
24        },
25      })
26    )
27  );
28
29  constructor(private actions$: Actions, private backend: Backend) {}
30}

Pessimistic Updates

To achieve a more reliable data synchronization, the pessimisticUpdate operator updates the server data first. When the change is reflected in the server state, changes the client state by dispatching an action. pessimisticUpdate method enforces the order of the fetches and error handling.

1import { Actions, createEffect, ofType } from '@ngrx/effects';
2import { pessimisticUpdate } from '@nrwl/angular';
3
4@Injectable()
5class TodoEffects {
6  updateTodo$ = createEffect(() =>
7    this.actions$.pipe(
8      ofType('UPDATE_TODO'),
9      pessimisticUpdate({
10        // provides an action
11        run: (action: UpdateTodo) => {
12          // update the backend first, and then dispatch an action that will
13          // update the client side
14          return this.backend.updateTodo(action.todo.id, action.todo).pipe(
15            map((updated) => ({
16              type: 'UPDATE_TODO_SUCCESS',
17              todo: updated,
18            }))
19          );
20        },
21        onError: (action: UpdateTodo, error: any) => {
22          // we don't need to undo the changes on the client side.
23          // we can dispatch an error, or simply log the error here and return `null`
24          return null;
25        },
26      })
27    )
28  );
29
30  constructor(private actions$: Actions, private backend: Backend) {}
31}

Data Fetching

The fetch operator provides consistency when fetching data. If there are multiple requests scheduled for the same action, it will only run the last one.

1import { Actions, createEffect, ofType } from '@ngrx/effects';
2import { fetch } from '@nrwl/angular';
3
4@Injectable()
5class TodoEffects {
6  loadTodos$ = createEffect(() =>
7    this.actions$.pipe(
8      ofType('GET_TODOS'),
9      fetch({
10        // provides an action
11        run: (a: GetTodos) => {
12          return this.backend.getAll().pipe(
13            map((response) => ({
14              type: 'TODOS',
15              todos: response.todos,
16            }))
17          );
18        },
19
20        onError: (action: GetTodos, error: any) => {
21          // dispatch an undo action to undo the changes in the client state
22          return null;
23        },
24      })
25    )
26  );
27
28  constructor(private actions$: Actions, private backend: Backend) {}
29}

This is correct, but we can improve the performance by supplying an id of the data by using an accessor function and adding concurrency to the fetch action for different ToDo's.

1import { Actions, createEffect, ofType } from '@ngrx/effects';
2import { fetch } from '@nrwl/angular';
3
4@Injectable()
5class TodoEffects {
6  loadTodo$ = createEffect(() =>
7    this.actions$.pipe(
8      ofType('GET_TODO'),
9      fetch({
10        id: (todo: GetTodo) => {
11          return todo.id;
12        },
13
14        // provides an action
15        run: (todo: GetTodo) => {
16          return this.backend.getTodo(todo.id).map((response) => ({
17            type: 'LOAD_TODO_SUCCESS',
18            todo: response.todo,
19          }));
20        },
21
22        onError: (action: GetTodo, error: any) => {
23          // dispatch an undo action to undo the changes in the client state
24          return null;
25        },
26      })
27    )
28  );
29
30  constructor(private actions$: Actions, private backend: Backend) {}
31}

With this setup, the requests for Todo will run concurrently with the requests for Todo 2.

Data Fetching On Router Navigation

Since the user can always interact with the URL directly, we should treat the router as the source of truth and the initiator of actions. In other words, the router should invoke the reducer, not the other way around.

When our state depends on navigation, we can not assume the route change happened when a new url is triggered but when we actually know the user was able to navigate to the url. The navigation operator checks if an activated router state contains the passed in component type, and, if it does, runs the run callback. It provides the activated snapshot associated with the component and the current state. And it only runs the last request.

1import { Actions, createEffect, ofType } from '@ngrx/effects';
2import { navigation } from '@nrwl/angular';
3
4@Injectable()
5class TodoEffects {
6  loadTodo$ = createEffect(() =>
7    this.actions$.pipe(
8      // listens for the routerNavigation action from @ngrx/router-store
9      navigation(TodoComponent, {
10        run: (activatedRouteSnapshot: ActivatedRouteSnapshot) => {
11          return this.backend
12            .fetchTodo(activatedRouteSnapshot.params['id'])
13            .pipe(
14              map((todo) => ({
15                type: 'LOAD_TODO_SUCCESS',
16                todo: todo,
17              }))
18            );
19        },
20
21        onError: (
22          activatedRouteSnapshot: ActivatedRouteSnapshot,
23          error: any
24        ) => {
25          // we can log and error here and return null
26          // we can also navigate back
27          return null;
28        },
29      })
30    )
31  );
32
33  constructor(private actions$: Actions, private backend: Backend) {}
34}

The StoreRouterConnectingModule must be configured with an appropriate serializer. The DefaultRouterStateSerializer provides the full router state instead of the MinimalRouterStateSerializer that is used without configuration.

1import { NgModule } from '@angular/core';
2import {
3  StoreRouterConnectingModule,
4  DefaultRouterStateSerializer,
5} from '@ngrx/router-store';
6
7@NgModule({
8  imports: [
9    StoreRouterConnectingModule.forRoot({
10      serializer: DefaultRouterStateSerializer,
11    }),
12  ],
13})
14export class TodosModule {}