I just finished implementing data polling using ngrx effects. For those unfamiliar with ngrx, it is a popular library for implementing the Redux pattern in Angular applications.

To implement data polling with ngrx effects, you can create an effect that listens for a specific action, such as a POLL_DATA action. When this action is dispatched, the effect can perform an HTTP request to retrieve the data from a remote server, and then dispatch a new action with the data.

You can use the @Effect decorator to create an effect that listens for specific actions. The @Effect decorator takes an options object as an argument, which allows you to specify the action that the effect should listen for and the effect’s behavior.

For example, you might create an effect that listens for the POLL_DATA action and performs an HTTP request to retrieve the data like this:

@Injectable()
export class PollingEffects {
  pollData$: Observable<Action> = this.actions$.pipe(
    ofType(POLL_DATA),
    switchMap(() =>
      this.http.get('/api/data').pipe(
        map((data) => ({ type: DATA_RECEIVED, payload: data })),
        catchError(() => of({ type: DATA_REQUEST_FAILED }))
      )
    )
  );
}

This effect listens for the POLL_DATA action and then performs an HTTP request using the HttpClient service. If the request is successful, it dispatches a DATA_RECEIVED action with the received data as the payload. If the request fails, it dispatches a DATA_REQUEST_FAILED action.

To ensure that the data is polled at regular intervals, you can use the interval operator from the RxJS library. You can modify the effect above to poll the data every 10 seconds like this:

@Injectable()
export class PollingEffects {
  pollData$: Observable<Action> = this.actions$.pipe(
    ofType(POLL_DATA),
    switchMap(() => interval(10000)),
    switchMap(() =>
      this.http.get('/api/data').pipe(
        map((data) => ({ type: DATA_RECEIVED, payload: data })),
        catchError(() => of({ type: DATA_REQUEST_FAILED }))
      )
    )
  );
}

In this modified version of the effect, the interval operator is used to emit a value every 10 seconds (10000 milliseconds). The effect then uses the switchMap operator to perform an HTTP request every time the interval emits a value.

To stop the data polling, you can simply dispatch a new action that the effect can listen for and respond to.

For example, you might create a STOP_POLLING action that the effect can listen for and use to stop polling the data. You can modify the effect above to stop polling when the STOP_POLLING action is dispatched like this:

@Injectable()
export class PollingEffects {
  pollData$: Observable<Action> = this.actions$.pipe(
    ofType(POLL_DATA),
    switchMap(() =>
      interval(10000).pipe(takeUntil(this.actions$.pipe(ofType(STOP_POLLING))))
    ),
    switchMap(() =>
      this.http.get('/api/data').pipe(
        map((data) => ({ type: DATA_RECEIVED, payload: data })),
        catchError(() => of({ type: DATA_REQUEST_FAILED }))
      )
    )
  );
}

In this modified version of the effect, the takeUntil operator is used to stop the data polling when the STOP_POLLING action is dispatched. The takeUntil operator takes an observable as an argument and completes the source observable (in this case, the interval observable) when the argument observable emits a value.

To use this modified effect, you can dispatch the POLL_DATA action to start polling and the STOP_POLLING action to stop polling.

To create a unit test for the data polling effect using the TestScheduler from the RxJS library, you can use the following steps:

First you have to modify your effect to use asyncScheduler like this:

@Injectable()
export class PollingEffects {
  pollData$: Observable<Action> = this.actions$.pipe(
    ofType(POLL_DATA),
    switchMap(() =>
      interval(10000, asyncScheduler).pipe(
        takeUntil(this.actions$.pipe(ofType(STOP_POLLING)))
      )
    ),
    switchMap(() =>
      this.http.get('/api/data').pipe(
        map((data) => ({ type: DATA_RECEIVED, payload: data })),
        catchError(() => of({ type: DATA_REQUEST_FAILED }))
      )
    )
  );
}

In this modified version of the effect, the interval operator is called with the asyncScheduler as the second argument. This causes the interval to use the asyncScheduler to schedule its emissions.

The asyncScheduler is a scheduler that schedules work asynchronously, using the JavaScript interval function. This can be useful if you want to simulate a delay in the data polling effect, or if you want to ensure that the effect is run outside the Angular zone.

I hope this helps clarify how to use the asyncScheduler with the data polling effect. Next you will add your unit tests file and follow the steps:

1. Import the TestScheduler from the RxJS library. The TestScheduler is used to control the virtual time in the test;
2. Create an instance of the TestScheduler and set up the test actions and expected results. To do this, you will need to define the actions that the effect should listen for and the expected results of the effect.
3. Set up the dependencies for the effect under test. This will typically include any services or dependencies that the effect uses, such as the HttpClient service. You can use mock implementations of these dependencies to control their behavior in the test.
4. Create an instance of the effect under test and pass in the dependencies.
5. Pass TestScheduler instance into the effect that is under test. This will execute the effect with a virtual timer.

Here is an example of a unit test for the data polling effect using the TestScheduler:

@Injectable()
export class PollingEffects {

    pollData$ = createEffect(() => ({ scheduler = asyncScheduler} = {}) =>
    this.actions$.pipe(
      ofType(POLL_DATA),
      switchMap(() => interval(10000, asyncScheduler).pipe(
        takeUntil(this.actions$.pipe(ofType(STOP_POLLING)))
      )),
      switchMap(() => this.http.get('/api/data').pipe(
        map(data => ({ type: DATA_RECEIVED, payload: data })),
        catchError(() => of({ type: DATA_REQUEST_FAILED }))
      ))
    )
  );

}

To use the createEffect function from the ngrx library with the data polling effect, you can modify the effect like this:

The createEffect function takes a function that returns an observable as an argument, and returns an observable of actions. The function that is passed to createEffect should contain the logic for the effect.

In this modified version of the effect, the createEffect function is used to wrap the logic for the effect in a way that is compatible with the ngrx store. The effect listens for the POLL_DATA action and performs an HTTP request to retrieve the data every 10 seconds (10000 milliseconds) using asyncScheduler. If the request is successful, it dispatches a DATA_RECEIVED action with the received data as the payload. If the request fails, it dispatches a DATA_REQUEST_FAILED action.

I hope this helps clarify how to use the createEffect function with the data polling effect.

Using ngrx effects to implement data polling is a straightforward process. Essentially, you can create an effect that listens for a specific action, such as a POLL_DATA action, and performs an HTTP request to retrieve data from a remote server. The effect can then dispatch a new action, such as a DATA_RECEIVED action, with the received data as the payload.

To stop the data polling, you can simply dispatch a new action, such as a STOP_POLLING action, that the effect can listen for and use to stop the data polling process.

Unit testing this effect is a bit tricky but you got it!

Hope all the code examples help you!

Hope you enjoyed this article.

Sharing data in the Angular application

When it comes to sharing data between components in an Angular application we have to remember that there more than one right way to do it!

Let’s go over some assumptions, rules, and considerations for this article.

Consider: Follow a container presenter pattern. Check out my video on this here.

Your components have as little responsibility as possible; whether it is to get data from the server or just display it.

You create dumb components whenever possible.

You keep your dependency injections in the components to a minimum.

You abstract business logic to the services.

Assumptions: You don’t always have the luxury of adding a state management library to your application.

I used NGRX and I know that it is a complex library and if the whole team is not on board to use it, then your code becomes a mish-mash of different approaches.

Get the whole team to commit to a state management library or go with another approach like the one described here.

Rules: Keep application performance at the top of the priority list.

Your code has to be clean and easy to read and maintain.

Say No to bubbling up events.

Here is an example of 3 components that all produce data. They have no access to the data they create. Events bubble up to the app.component.

I want to show you what NOT to do!

checkout StackBlitz:

https://stackblitz.com/github/katesky/messages-sent-app

Next up is code where we will add a service that will manage our data and it will be shared with all of our components.

Use service with a subject

git checkout with-service or go to code here –> new branch

We will create a service that will hold a list of our data in a private BehaviorSubject of type an array of strings.

We will add a public observable of that BehaviorSubject to our service.

Now we can add a function that will mutate our data.

We now have a central area where our data is held.

It can be shared across all of our components and there are no events that have to be emitted up to the parents’ components.

Now that our application is truly reactive we can change out changeDetection to OnPush. More info on it here.

Change template to using async pipe. Read about it here!

We can use data$ in all other components the same way as here:

Checkout Stackblitz with code complete:

https://stackblitz.com/github/katesky/messages-sent-app/tree/with-service

I hope this article was usefull for you.

I was able to show you something new and you will avoid some of the mistakes I made when I got started with Angular.

One of my passions is to be able to inspire mothers to get started in technology sector. I am a programmer with over 20 years of experance in IT.

I am also a mother of 5 children. I hope one day my daughters will be inspired by my story to go into STEM.

Till next time!

Kate Sky.

Angular NGRX enabling DevTools at runtime

In this article, I will cover a problem that I was working on in one of my projects. With help from the NGRX team, I was able to solve it.  Shot-out to @brandontroberts , @tim_deschryver, @AlexOkrushko!

I hope it helps you when using NGRX, and you can also add it as part of your development process. 

Problem:

I wanted to be able to enable DevTools at runtime. The reason I want to do that is to be able to let users report his/her application experience and especially the problems they are experiencing. 

In other words, enable debugging reporting on the fly using NGRX framework.

Solution:

This article will be useful if you love Redux DevTools, but you don’t have them enabled in Production.

You would like to have your application to be able to switch to the reporting mode, even in Production.

I will cover the following steps:

1. Adding a lazy-loaded Feature Module
2. Dispatching an effect to create a StoreDevtoolsModule at runtime
3. Extras:
   1. Use hidden F1 key to enable a link for debugging. 
   2. Enable third party logging/debugging tools  

Implementation:

We start by adding a feature; we will call it ‘debug’.  

It will contain:

1.  debug.action – We will use an NGRX action from this file to dispatch from the component.
2. debug.component. We will use Debug component to load our feature via a new route we will add to app.module. 
3. debug.module – We will lazy-load this module that in the app.module, and it will contain a route to the component
4. app.module – Register a new feature with a lazy-loaded route
5. dev-tools.module – Module that will inject the StoreDevTools to kick-of the Redux tools registration from this module.
6. debug.effect – We will use this NGRX effect to catch an action dispatched. This effect will be responsible for the runt-time enabling of the dev tools.
7. root-store.module – Register new Effect in RootModule
8. app.componet – Add a hiddent button that can be turned visible by F1- hot key

debug.action.ts

Add a new action to be dispatch to the store about the state change.

We prefix the type of the action with the name of the page that will dispatch this action.

import { createAction } from '@ngrx/store';

export const enableDebug = createAction('[Debug Page] enable');

debug.component.ts

Add a new component. If you like, you can keep template and styles inline. Both are not used in this setup, so can easily be excluded.

I have an empty template because its not needed.

When component is loaded it will dispatch an action that will enable DevTools (line 14). Effect is below, I promise!

in terminal:

ng generate component debug--inlineTemplate=true --inlineStyle=true

in new file debug.component.ts:

import { Component, OnInit } from '@angular/core';
import { Store } from '@ngrx/store';
import { RootState } from '../+state/root.selectors';
import { enableDebug } from './debug.actions';

@Component({
  template: ``,
  selector: 'app-debug'
})
export class DebugComponent implements OnInit {
  constructor(private readonly store: Store<RootState>) {}

  ngOnInit(): void {
    this.store.dispatch(enableDebug());
  }
}

debug.module.ts

This module is lazy-loaded so it will be registering the child routes.

debug.module.ts:

import { NgModule } from '@angular/core';
import { DebugComponent } from './debug.component';
import { RouterModule } from '@angular/router';
@NgModule({
  imports: [ 
      RouterModule.forChild([{ path:'',component:DebugComponent}])
  ],
  declarations: [DebugComponent],
  exports: [DebugComponent]

})
export class DebugModule {
  constructor(){}
}

app.module.ts

This module we will add a new route and lazy-load it with a feature module.

This is a code-snipet , so if you want to see full code check out my repository.

{
    path: 'debug',
    loadChildren: () =>
    import('./debug/debug.module').then(
      m => m.DebugModule
    )
      
  },

dev-tools.module.ts

This module will be compiled and created in the effect.

On line 14th you can refresh the tools. I didn’t see much of a difference in value having it execute.

import { NgModule } from '@angular/core';
import { StoreDevtoolsModule, StoreDevtools } from '@ngrx/store-devtools';
@NgModule({
  imports: [
    StoreDevtoolsModule.instrument({
      maxAge: 25, // Retains last 25 states
      logOnly: true
    })
  ]
})
export class DevToolsModule {
  constructor(private storeDevtools: StoreDevtools) {
    // storeDevtools.refresh();
  }
} 

debug.effect.ts

Effect class is responsible for reacting to the action dispatched from the component. It filters out actions that it is subscribing to and when enableDebug is dispatched, effect is using ‘exhaustMat’ operator to make sure that if same action is dispatched it will continue to execute. In other words dropping incoming request.

Next it uses injected compiler object to compile dev-tools.module and creates it on lines 21-24.

Once that is completed, we have devtools enabled and redux tools can be used to track our state changes.

We know that we will have a manual mechanism of turning debugging option on so we can redirect our user back to that location. In this case it’s root of the application or home. So the changeLink action is returned via this effect.

import { Injectable, Compiler, Injector } from '@angular/core';
import { createEffect, Actions, ofType } from '@ngrx/effects';

import * as DebugActions from './debug.actions';
import { exhaustMap } from 'rxjs/operators';
import { DevToolsModule } from './dev-tools-module'; 
import { changeLink } from '../+state/root.actions';

@Injectable()
export class DebugEffects {
  constructor(
    private actions$: Actions,
    private compiler: Compiler,
    private injector: Injector
  ) {}

  debugAction$ = createEffect(() =>
    this.actions$.pipe(
      ofType(DebugActions.enableDebug),
      exhaustMap(async () => {
        const m = this.compiler.compileModuleSync<DevToolsModule>(
          DevToolsModule
        );
        m.create(this.injector); 
        return changeLink({ link: '' });
      })
    )
  );
}

If you checkout my repository you will see that I just imported DevToolsModule into the DebugModule for simplicity. I kept the effect for other use case in Extra#2.

import { NgModule } from '@angular/core';
import { DebugComponent } from './debug.component';
import { RouterModule } from '@angular/router';
import { DevToolsModule } from './dev-tools-module';
@NgModule({
  imports: [ 
      RouterModule.forChild([{ path:'',component:DebugComponent}]),
      DevToolsModule
  ],
  declarations: [DebugComponent],
  exports: [DebugComponent]

})
export class DebugModule {
  constructor(){}
  
}

app.component.html

Add anywhere you would like to include a hidden button. So next time your user is having some unexplainable issues they can hit F1 and it will become visible.

Can you tell I am using material components? So if you this code make sure you import all necessary Modules for Material here.

<button *ngIf="isDebugVisible" (click)="onDebug()"mat-icon-button aria-label="debug">
  <mat-icon>bug_report</mat-icon>
</button>

app.component.ts

Extra #1: As promised I will give this little trick. I added hidden button to help user discover issues and be part of the debugging process.

We will add a function to make our button visible with HostListener, filtering out keys.

Next we will add a button click event that will redirect our user to the lazy-loaded module we just setup.

Remember: user will be redirected back here from the debug.effect?

So we can turn off the button – our devtools are enabled!

  onDebug() {
    this.store.dispatch(changeLink({ link: 'debug' }));
    this.isDebugVisible = false;
  }
  @HostListener('document:keydown', ['$event'])
  keypress(e: KeyboardEvent) {
    if (e.key === 'F1') {
      this.isDebugVisible = true;
    }
  }

Extras #2

If you haven’t heard of LogRocket yet. Let me Introduce you. www.logrocket.com This is a very cool product that you can plugin to the application to see a full path of your user experience with visual snap shots.

How cool is that?

If you follow their instruction it is pretty straight forward to include and get started with in your application.

https://app.logrocket.com/<replace-with-yourcode>/settings/integrations/

It is a paid product, if you exceed the number of requests that are free!

But let see if we can utilize a free version by only enabling the setup from our debug lazy-loaded module dev-tools.module?

update debug.effect.ts

import { Injectable, Compiler, Injector } from '@angular/core';
import { createEffect, Actions, ofType } from '@ngrx/effects';

import * as DebugActions from './debug.actions';
import { exhaustMap } from 'rxjs/operators';
import { DevToolsModule, LOGROCKET_INIT_KEY } from './dev-tools-module';
import * as LogRocket from 'logrocket'; 
import { changeLink } from '../+state/root.actions';

@Injectable()
export class DebugEffects {
  constructor(
    private actions$: Actions,
    private compiler: Compiler,
    private injector: Injector
  ) {}

  debugAction$ = createEffect(() =>
    this.actions$.pipe(
      ofType(DebugActions.enableDebug),
      exhaustMap(async () => {
        const m = this.compiler.compileModuleSync<DevToolsModule>(
          DevToolsModule
        );
        m.create(this.injector);
        LogRocket.init(LOGROCKET_INIT_KEY);
        return changeLink({ link: '' });
      })
    )
  );
}

update dev-tool.module.ts

import { NgModule } from '@angular/core';
import { StoreDevtoolsModule, StoreDevtools } from '@ngrx/store-devtools';
import { USER_PROVIDED_META_REDUCERS } from '@ngrx/store';
import * as LogRocket from 'logrocket';
import createNgrxMiddleware from 'logrocket-ngrx';
import { MetaReducer, State } from '@ngrx/store'; 
import { RootState } from '../+state/root.selectors';
const logrocketMiddleware = createNgrxMiddleware(LogRocket, {});

export const metaReducers: MetaReducer<any>[] = [];

export function getMetaReducers(): MetaReducer<RootState>[] {
  return metaReducers.concat([logrocketMiddleware]);
}
export const LOGROCKET_INIT_KEY = '<replace-with-your-code';

@NgModule({
  imports: [
    StoreDevtoolsModule.instrument({
      maxAge: 25, // Retains last 25 states
      logOnly: true
    })
  ],
  providers: [
  
    {
      provide: USER_PROVIDED_META_REDUCERS,
      useFactory: getMetaReducers
    }
  ]}
)
export class DevToolsModule {
  constructor(private storeDevtools: StoreDevtools) {
    // storeDevtools.refresh();
  }
}

Now that we have this setup, we can see our requests are only feeding into our LogRocket account after we enabled debug!

I hope you enjoyed this article! Tweet you questions or comments here.

I will be glad to connect too!

• Twitter
• Twitter

If you would like to see a repository where I added this implementation, follow this github link:

https://github.com/katesky/saraphan-radio/tree/azure/apps/shell-app/src/app/debug

Angular: front-end from start to MVP

by Kate Sky

I am making this post as the first step in documenting my journey of building an Enterprise application for my side project.

The application is in the process of going towards an MVP.

This application is an “Uber for home services.” 

The reason I had started this project: is to provide a value-based service while practicing and teaching others skills I had acquired over the years.

The objective of this post is to establish a timeline of the application going live from its infancy.

Following is the list of topics that we are going to discuss in this article:

1. Application Stack
2. Architectural decisions
   1. Monorepo with Nx
   2. Domain-Driven Design with Angular
   3. State management with NGRX
   4. Logging with LogRocket
   5. Authentication with Auth0
3. Conclusion
4. Links

1. Application Stack

WEB- Angular
API – .Net Core
DB – SQL server

2. Architectural decisions

For web client, I am using Angular framework.

My goal – to be able to scale the development of this application by having the ability to go from one team to many teams building multiple frontend and backend applications all in the same workspace. 

I chose NX, so developers have a holistic dev experience powered by an advanced CLI (with editor plugins), capabilities for controlled code sharing, and consistent code generation.

Monorepos allow huge enterprise applications to be subdivided into small and maintainable libraries. I followed the best practice from the creators of NX and have added a domain-driven design approach to creating the features. One of the features is the search capability for the providers that are displayed. I added a domain ‘Providers’ it contains the feature store for state management and the infrastructure where service is implemented to call the API.

We need to first define criteria for slicing our application into individual parts and we must establish rules for communication between them.

referenced: https://www.angulararchitects.io/aktuelles/sustainable-angular-architectures-1/

I have added NGRX from the very beginning because I would like to have an ability to replay the user’s trip through the application, and I will be adding LogRocket to view that path. NGRX will also help me write clean reactive components with async pipes. Root store has its own module and is at the root of the application.

Stop guessing why bugs happen. LogRocket lets you replay what users do on your site, helping you reproduce bugs and fix issues faster.

https://logrocket.com/

Since we have 2 features now, we can see that NGRX stores for each feature are located near the domain for each feature’s library. There is separate module for each store to be able to import each feature module lazily.

Users have to register, and for authentication, I picked Auth0. Right now, you can see that authentication is on the root store. I have a login and logout actions that are calling the service to execute the correct code. I am using the service I download from the example provided by auth0. It still needs to be cleaned up. 

I added a component for the callback path need for the login of the authentication. There is a CanActivate guard that is used for components that need an authorized user.

3 . Conclusion

In conclusion, we will go through whats next.

I wanted to get the frontend started first and have a clear user experience throughout the application.

I will add the .net Core API to store the data to the database next.

I deployed code to GitHub pages to be able to get user feedback at the very early stages of this application.

4. Links

Code: https://github.com/katesky/saraphan-radio

Dev version: https://katesky.github.io/saraphan-radio/

Domain: http://saraphanradio.com

Angular: NGRX clean architecture with multiple stores

by Kate Sky

Before we go into Part 2 (testing of the multi-feature/store), I want to demonstrate the implementation of lazy loading of modules with multiple stores. So the objective of this article will be to show you how to add feature stores to the Feature module, which are loaded lazily when a route is activated.

Finally, I am going to provide links to the repository to GitHub.

Following is the list of topics that we are going to discuss in this article:

1. Application objective.
2. Application architecture
3. Lazy loading of the feature modules
4. Lazy loading demo
5. Conclusion
6. Links
7. Part 2 ( to be continued)

1. The objective of the application     

In this example, I want to demonstrate an app that will track home buying data. It will have a dashboard with links to a favorite list and a list of visited homes. Users will also be able to click on a link that will take her to a list of all prospective homes. From there, she can go into detail for each home.  

2. Application architecture and folder structure

In this example, we have separated this application in high-level feature modules. By doing so, it allows us to lazy load features along with store modules based on the current route.

3. Lazy loading of the feature modules

“By default, NgModules are eagerly loaded, which means that as soon as the app loads, so do all the NgModules, whether or not they are immediately necessary. For large apps with lots of routes, consider lazy loading—a design pattern that loads NgModules as needed. Lazy loading helps keep initial bundle sizes smaller, which in turn helps decrease load times. ” – From Angule.io

We now can lazy load our feature module by registering it in the routing module:

4. Lazy loading demo

When we have a clean separation of the features into modules, it allows us to register routes to be lazy-loaded.
Let’s see it in action by checking the console:

When app navigates to Homes we see that our feature1 module is fetched and an additional file appears in the console:

5. Conclusion

In this article, I tried to deliver a technical guide on how to organize your application NGRX stores and provide you with examples of how they can be registered alongside with routing modules.

We started with an application description. I went over the architecture and folder structure. We then looked at registering a lazy loaded module. Finally, we looked at the demo.

6. Links

• https://github.com/katesky/ngrx-multy-store-part-1.5
• https://stackblitz.com/edit/ngrx-multy-store-part-15

7. Part 2 (To be continued…)

Where I will show how to test a component that uses a feature store. Some mocking will take place.

I hope this article helps you out with adding NGRX to your application.

Angular: NGRX clean architecture with multiple stores

by Kate Sky

The objective of this article is to provide a technical implementation of the NGRX for an application with a complexity that could benefit from adding feature store(s) in addition to the root store.

Finally, I am going to provide links to my GitHub repository with the example code.

In part 2, I will show how to unit test components that use a feature store and later we will go into the unit testing of the NGRX store itself.

This is the list of topics that we are going to discuss in this article:

1. A high-level use case for state management.
2. Getting started with a root store
3. Adding feature store to the application
4. Organizing your store folders
5. Adding stores to your components
6. Conclusion
7. Links
8. Part 2 ( to be continued)

1. High-level use case for state management.

When a decision has been made to manage the state of your complex application by adding NGRX, it is important to understand that you will not be able to convert the whole application to use the store right from the start.

It will be a gradual process that I will try to provide a technical guide for. In the example, you will see a RootStoreModule and a Store1Module.

The root store is where you will start. This store will be the highest level of user/system actions that can be performed in the application. For example, a dashboard app will have links to other areas, so the root store will load the available links and user access and privileges needed for the app to run. Root store will manage the state of the highest level of the application or lowest since it is a root (pun attended).

The feature store is an abstraction for parts of the application that are feature-based. For example, the user will click on a feature of the application from a dashboard, that allows him to manage orders, sales, employees, etc.  This is where the feature will load or change data using the feature store. It will manage the state of this feature along.

First, you must install NGRX by following the installation steps from https://ngrx.io/guide/store/install

2. Getting started with a root store

Second, you will create a folder where you will hold all files related to the root store.

Inside the folder, you will have files needed for the store: actions, effects, reducers and an index file for exports. One of the necessary imports is CommonModule and reducers and effects.

If you use the CLI’s “ng add @ngrx/store” the structure is flatter. I like to organize it in a more 2D way.

Second, you will add the RootStoreModule to the app.module( CLI will add it for you!)

3. Adding Feature store to the application

When adding a feature store module and adding the imports one major difference from the root is the forFeature method.

Ones all the files are created you can add feature module to the app.module just like the RootStoreModule

4. Organizing your store folders

In this simple example, you can see a separate folder for the feature store on the same level as the root store, but in a real application, I recommend adding a feature store folder on the same level as the feature folder.

5. Adding stores to your components

Since this example uses both stores in the app component, it’s pretty clear how easy it is to use the store and create a truly reactive application using an NGRX store.

In AppComponent you can find root store and feature store usage.

Stores are injected into the constructor and actions are dispatched to load the data:

You can see that the template is using the async pipe to load the data, there are no subscribe events. Observables are assigned the selectors from the store:

6. Conclusion

In this article, I tried to deliver a technical guide on how to organize your application NGRX stores and provide you with examples of how they can be organized.

We started by setting up the root and feature stores and registering them in the app module. We then added the stores to a component and saw how data is displayed on the screen.

7. Links

• https://github.com/katesky/ngrx-multy-store
• https://stackblitz.com/edit/github-ngrx-multy-store
• https://github-ngrx-multy-store.stackblitz.io

8. Part 2 (To be continued…)

Where I will show how to test a component that uses a feature store. Some mocking will take place.

I kept this project as simple as possible, so you can even take the source code and add it to your application as a template. I know I will in the future.

I hope this article helps you out with adding NGRX to your application.

Using custom selectors for one-to-one or one-to-many data relationships.

by Kate Sky

When implementing state management with Ngrx we often have a predefined API that can not be changed. I ran across a business case: back end API is written in a way where 2 sets of data that are returned are depend on the other. One-to-one or one-to-many relationship. In order to map entities with corresponding ids we have to create a custom selector.

To make a selector that will do a lookup of another selector just add 4 Actions, 2 Effects and 3 selectors:

This is a declaration of the 2 Actions

export class LoadStudents implements Action{
  readonly type = ActionTypes.LoadStudents;
}
export class LoadTeachers implements Action{
  readonly type = ActionTypes.LoadTeachers;
}
export class Students implements Action{
  readonly type = ActionTypes.Students ;
  constructor(public payload: any){}
}
export class Teachers implements Action{
  readonly type = ActionTypes.Teachers;
  constructor(public payload: any){}
}
export type ActionUnion = LoadStudents| LoadTeachers
| Students  | Teachers  ;

This is an implementation of the 2 effects

@Injectable()
export class Effects {

  constructor(private actions$: Actions, private service: myService ) { 
    }

    @Effect()
    loadStudents$ = this.actions$.pipe(
        ofType<appActions.LoadStudents>(appActions.ActionTypes.LoadStudents),
         switchMap(() => this.service.getStudents().pipe(
          map((data) =>         
             new appActions.Students(data)
         ))));
    

    @Effect()
    loadTeachers$ = this.actions$.pipe(
        ofType<appActions.LoadTeachers >(appActions.ActionTypes.LoadTeachers ),
       switchMap(() => this.service.getTeachers().pipe(
          map((data) =>         
             new appActions.Teachers(data)
         ))));
    
}

When declaring selectors you have to remember that order of loaded data is not predictable and we have to account for it not all being loaded yet:

export interface State {
    csaApp: fromFeatures.State
}
export const reducers:ActionReducerMap<State>= {
    csaApp: fromFeatures.filteredAppReducer

}
const getAppState = createFeatureSelector<fromFeatures.State>('csaApp');
export const getStudents = createSelector(getAppState, (state)=>state.students);
export const getTeachers= createSelector(getAppState, (state)=>state.teachers);
export const getStudentsWithTeachers = createSelector(getStudents, getTeachers,(students, teachers) => {
    if(students === null || teachers === null) return null;
    students.map(s=>s.teacher = teachers.find(t=>t.id ===s.teacherId));
    return students;
}) 

Statement management using Ngrx is a huge subject and creating custom selector will be a great addition to any angular project.

See my github repository for a work-in-progress project I am workig on to support elementary school events for my children’s’ school. https://github.com/katesky/csa-school-app

To see the working (wip) site visit: https://katesky.github.io/csa-school-app