loading...

Where to initiate data load in NgRx

jonrimmer profile image Jon Rimmer Updated on ・6 min read

In NgRx, loading data from a data source, such as a REST API or a DB, is done using an effect. However, something has to dispatch the action that triggers the effect in the first place. I've seen a few different suggestions / approaches to doing this.

In our example, we'll be loading a collection of Order entities from a service. We'll introduce two actions: LoadOrdersRequested and LoadOrders. The first of these will initiate the data load, then an effect will perform the load and dispatch a LoadOrders action, which will put the loaded data into the store.

The effect to handle LoadOrdersRequested will look like this:

@Effect()
loadOrdersRequested$ = this.actions$.pipe(
  ofType<LoadOrdersRequested>(ActionTypes.LoadOrdersRequested),
  // Don't load if we've already loaded.
  withLatestFrom(this.store.select(getAllOrdersLoaded)),
  filter(([_, loaded]) => !loaded),
  // Don't handle more than one load request at a time.
  exhaustMap(() => this.ordersService.fetchAllOrders().pipe(
    map(result => new LoadOrders(result))
  ))
);

Now, in order to initiate the data load, we need to dispatch the LoadOrdersRequested action from somewhere. There are four main options:

  1. When the app starts.
  2. When a container component is initialised.
  3. When the app navigates to a route.
  4. When the user performs an action.

The fourth of these might be when the user clicks a button to explicitly load or reload some data. For this article we'll concentrate on the first three.

When the app starts

Pros:

  • The data is guaranteed to load.

Cons:

  • Memory / performance concerns if there's a lot of data to load.

In your AppComponent

The simplest way is to dispatch the LoadOrdersRequested action from your AppComponent's init lifecycle method:

export class AppComponent implements OnInit  {
  constructor(private store: Store<AppState>) {}

  ngOnInit() {
    this.store.dispatch(new LoadOrdersRequested());
  }
}

https://stackblitz.com/edit/angular-ngrx-initiate-load-at-app-start-app-component

In an effect

NgRx provides an INIT action that is dispatched when the app starts. This seems like a good place to initiate our data load, but there's a problem. The INIT action is dispatched before the effects are subscribed to, so this won't work:

@Effect()
init$ = this.actions$.pipe(
  ofType(INIT),
  map(() => new LoadOrdersRequested())
);

Instead, the NgRx team has recommended using the defer RxJS operator instead:

@Effect()
init$ = defer(() => new LoadOrdersRequested());

However, if we want to have our effect potentially trigger other effects, this approach will not work. This is because, while defer delays the creation of the LoadOrdersRequested action until the init$ observable is subscribed to (during the effects module initialisation), the action will then be dispatched before the initialisation is complete. As such, our effect that is looking for LoadOrdersRequested may not be registered yet, depending on the order in which the effects system has subscribed to the different effects.

We can perhaps mitigate this problem by re-ordering out effects, but a better solution is to use the asyncScheduler to delay to dispatch of the LoadOrdersRequested action:


import { asyncScheduler, of } from 'rxjs';

...

@Effect()
$init = of(new LoadOrdersRequested, asyncScheduler);

Although INIT does not work, there is also a built-in action we can use: ROOT_EFFECTS_INIT:

@Effect()
$init = this.actions$.pipe(
  ofType(ROOT_EFFECTS_INIT),
  map(() => new LoadOrdersRequested())
);

https://stackblitz.com/edit/angular-ngrx-initiate-load-at-app-start-init

APP_INITIALIZER

Angular provides APP_INITIALIZER as a way to run code at app startup, and you can dispatch actions from there:

@NgModule({
  ...
  providers: [
    {
      provide: APP_INITIALIZER,
      useFactory: (store: Store<AppState>) => {
        return () => {
          store.dispatch(new LoadOrdersRequested());
        };
      },
      multi: true,
      deps: [Store]
    }
  ]
})

https://stackblitz.com/edit/angular-ngrx-initiate-load-at-app-start-app-initializer

When a container component is initialised

Pros:

  • You only load data as and when it's needed.
  • It's clear from looking at the component what data it's relying on.

Cons:

  • You either need lots of actions, or to dispatch the same action in several places.
  • The component is less pure, as it has the side effect of loading data.
  • You might forget to dispatch the action from a component that needs the data. This bug could be obscured if you normally reach the component through another component that does initiate the data load. E.g. you normally open a list page before opening a details page. Then, one day, you navigate directly to the details page and it breaks.
@Component({ ... })
export class OrdersComponent implements OnInit {
  order$: Observable<Order>;

  constructor(private store: Store<AppState>) {
    this.order$ = this.store.select(getOrder);
  }

  ngOnInit() {
    this.store.dispatch(new LoadOrdersRequested());
  }
}

https://stackblitz.com/edit/angular-ngrx-initiate-load-in-component

When the app navigates to a route

Pros:

  • Less duplication. A single guard at the root of a route hierarchy can load the data for all child routes, even if they're navigated to directly.
  • Components are more pure, as they only map from selected state to their template output.

Cons:

  • Quite blunt: A guard will trigger data load for any child route, even if its component doesn't need it.
  • Less obvious from looking at a component what data it needs to work. If it gets moved somewhere else in the router hierarchy, it'll break.
  • Less useful if routes requiring some particular data are spread out throughout the router hierarchy, as you'll need to include the guard in different places.

Router Guard

@Injectable()
export class OrdersGuard implements CanActivate {
  constructor(private store: Store<AppState>) {}

  canActivate(): Observable<boolean> {
    return this.store.pipe(
      select(getAllOrdersLoaded),
      tap(loaded => {
        if (!loaded) {
          this.store.dispatch(new LoadOrdersRequested());
        }
      }),
      filter(loaded => loaded),
      first()
    );
  }
}


const ROUTES: Route[] = [
  {
    path: 'orders',
    component: OrdersList,
    canActivate: [OrdersGuard],
    children: [
      ...
    ]
  }
]

https://stackblitz.com/edit/angular-ngrx-initiate-load-router-guard

A basic guard could just dispatch the LoadOrdersRequested action, relying on the effect to filter out unnecessary load requests. However, by checking the condition of allOrdersLoaded, the guard can delay the navigation until the load is completed.

Router Resolver

@Injectable()
export class OrdersResolver implements Resolve<boolean> {
  constructor(private store: Store<DatasetsState>) { }

  resolve(): Observable<boolean> {
    return this.store.pipe(
      select(allDatasetsLoaded),
      tap(loaded => {
        if (!loaded) {
          this.store.dispatch(new AllDatasetsRequested());
        }
      }),
      filter(loaded => loaded),
      first()
    );
  }
}

https://stackblitz.com/edit/angular-ngrx-initiate-load-router-resolve

Using a resolver works very similarly to a guard. The main difference is that a resolve is run under somewhat different circumstances to a guard, and is supposed to return an object to be merged into the activated route's data. However, we should not do this, as components should be retrieving the data from the store, not from the activated route. As such, the resolve should simply return a boolean.

Router Action Effect

@Effect()
loadOrders$ = this.actions$.pipe(
  ofType<RouterNavigationAction>(ROUTER_NAVIGATION),
  withLatestFrom(this.store.select(allOrdersLoaded)),
  filter(([action, loaded]) => 
    action.payload.routerState.url.includes('/orders') && !loaded
  ),
  map(() => new LoadOrdersRequested())
);

Pros:

  • Keeps things within NgRx, so feels more idiomatic.

Cons:

  • Requires you check if the new route matches, rather than relying on the router itself to do this as the guard approach does. This could cause loading bugs if someone changes a path in your router config, but forgets to do so in your effects.

Dispatch an action from a check inside a selector

export function getAllOrders(store: Store<AppState>) { 
  return createSelector(
    getOrders,
    state => {
      if (!state.allOrdersLoaded) {
        store.dispatch(new LoadOrdersRequested());
      }

      return state.orders;
    }
  );
}

I've not actually seen this done in the wild, but it's an approach that occurred to me.

Pros:

  • Guarantees to load the data if and only if it's been queried for use.

Cons:

  • Violates principle that selectors should be pure functions.
  • If you're not rigorous about reusing and combining your selectors, you could end up with some that trigger the load and some that don't because they defer to the selector that triggers the load.

Future possibilities

It sounds as if Angular Ivy may open up the possibility of using meta-programming on components to configure things like store dependencies in a more declarative way.

Conclusion

I'm not sure any one of these approaches obviously wins over all the others in all situations. You are probably best choosing an approach based on the number of data sources you need to load, the volume of data, and the complexity and layout of your router tree.

E.g. if you have a small, simple app, with a low data volume, eagerly loading everything at INIT is probably the best idea.

However, if you have a large app, split into different features, with each feature needing to load data from a separate source, it might be best to use a guard at the root of each feature's route hierarchy to dispatch the load action for its requirements.

If you have a complex app, with various containers having partially overlapping data requirements, it might be best to have each container dispatch the actions to load what they need.

Posted on by:

Discussion

markdown guide
 

NgRx 7 brings us some new Effect lifecycle hooks.
One of them, OnInitEffects, might be useful to initiate a data load when an effect gets registered - see docs.

class OrdersEffects implements OnInitEffects {
  ngrxOnInitEffects(): Action {
    return { type: '[Orders Effect]: Load' };
  }
}
 

What about dispatching action in APP_INITIALIZER? Or a Resolver?

 

I was about to say the same thing. Actually, dispatching on a resolver is one of the most common things I do in an Angular+NgRx project.

Nice recap anyway.

 

Good point about APP_INITIALIZER. I did consider Resolver, but I figured it was similar enough to Guard. I'll update the article with both approaches.

 

Great post Jon, There was two ways that works for me to dispatch an action when the app starts:

@Effect()
  $init = of(new ListenAuth, asyncScheduler);

But as Tim Descrhryver saids onInit Effects also works if you use NgRx7:

ngrxOnInitEffects(): Action {
    return { type: '[Login]: Listen Auth' };
  }
 

One tiny bit to add, hope this use case is not unique to me. Some data is a cache that does not need to update all that often. Such data is best loaded in the component or router. That is because 1. some of it might have been persisted to localstorage or forage and hydrated into the state 2. some of it might not be stale yet (e.g. my use case I want to invalidate at most once an hour) 3. Critically I want to provide the user the choice to refresh (i.e fetch the latest) - in the same page (smart component) where this info is to be displayed. It means the cache validation will happen onInit, and forceful update on a button click.

 

Thank you Jon, nice post!
What should I do if I have a lot of complex entities (customer > address > country) and I don't want to load all of them in the state at once?

Basically, I need to "fetch" entities on selectors but I don't want to break the pattern.

Anyway, great work!

 

This is a good question, and it's one I've struggled with myself, and I'm not sure there is a perfect (or even a good) answer for NgRx / Redux as it stands. Usually what I end up doing is having the component(s) interested in a particular entity dispatch a "load" action on ngInit, and then have an effect on this action that checks whether the entity is already present in the store, and then loads it from the back-end if its not. You can mirror this with an "unload" action when the component is destroyed which clears the entity out of the store, so reducing the amount of data you're storing.

However, I have often thought there is room in NgRx for something like a reference-counted selector, where the first subscription to a selector dispatches a "load" event, which can load a resource into the store, and where the subscriber count going back down to zero dispatches an "unload" event. RxJS already has capabilities for performing reference counting on shared observables, so you might be able to use this to create smart selectors in this fashion. I hope to experiment with doing this myself some time, but I haven't yet got around it to it.

 

I like an idea to dispatch action in selector, because this is the place where you actually know, do you have the data you need. However when I implemented a feature this way, I faced with strange behavior of NGRX\RxJS because in some point of time I receive initial state in the selector instead of updated. Maybe you know how to address this problem?

 

In NgRx, loading data from a data source, such as a REST API or a DB, is done using an effect. However, something has to dispatch the action that triggers the effect in the first place. I've seen a few different suggestions / approaches to doing this.

I seriously question this premise. Why does data have to fetched in an effect? In most cases getting data is not triggered by a user action but by displaying a component. That's a subscription: You get the observable from a service and subscribe via async pipe. The service passes you the store observable. If the store is empty, the service triggers a network request and dispatches an action to load the data into the store. Done.

 

I was looking for a proper exhaust map implementation of such guard, good work!
but there's a valuable piece missing - the 'loading' state which is set to true at the request dispatch, so on the following dispatches it just leaves the loading state on true

 

Fantastic. I somehow didn’t know about APP_INITIALIZER. I may use that.

 

Hey Jon,

Thank you for this great article, I am a bit confused because of my set up, I hope you could help me understand.

In my app, I have couple modules which are using the StoreModule.forFeature flag so when I look for the "state" of those features I get a warning. telling that the state doesn't exist.

So I move the StoreModule.forFeature to the app module then it works. however the module for that feature doesn't anymore.

here is what my route looks like....

Also I am using the 'Route Guard
{
path: 'claim/:extClmId/client/:extClient/role/:roleType', canActivate: [ValidationGuard],
children: [
{ path: '', loadChildren: () => import('libs/lazy/firstview/src').then(m => m.FirstModule), canActivate: [OverviewGuard] },
{ path: 'preferences', loadChildren: () => import('@hub/lazy/preferences').then(m => m.SecondModule) },
],
},
{ path: 'error', loadChildren: () => import('@hub/lazy/four-oh-four').then(m => m.FourOhFourModule) },

OverviewGuard is what I am using to load my data but is it not the on the app.module level. it is on the FirstModule level..... Hope I am making sense.

 

Thanks a lot for the post! Just a question: how would you handle loaders and errors when loading data in guards/resolvers?

 

A word of causion: if you use ROOT_EFFECTS_INIT you won't have access to the router selectors as they have not yet been initialized.