Using NgRx with Elements

Recently I’ve started a new project where we plan to restructure a large application into smaller, more manageable individual projects.
As well as dividing the application into small modules we want to set out a way that all the developers on the team can write each part of the application in a consistent way.

One approach we’re looking at in using Angular Elements with NgRx. Each individual sub-section of the application is loaded into the main parent application as an Angular Element and NgRx is used as the framework for having a consistent pattern through each application on how data and state is loaded.

I’ve used NgRx before, especially when writing a introduction to NgRx chapter of my book, Getting Started With Angular 8. So if want to learn about how to use NgRx check the chapter from my book. Using NgRx with Elements is something new to me, so this was an interesting exercise.

In a previous contract I’ve used Nx as a way to create something similar. We used Nx to manage all the sections of the application we created as Angular elements and generate a library which was used across all the sections of the application to share common functionality. This worked really well, but it did lead to all the code being in a monorepo.

In this new project we don’t want to have a monorepo, instead each sub-section is in its own repo. This allows a developer to get the single project and it makes managing the deployment easier. There are many pros and cons to using either a monorepo approach or not. For this client, the multi repo approach is what they have in place.

Using Angular Elements (which I admit when I first heard about Elements I wasn’t to sure on the benefit it would bring) is allowing us to really separate out each sub-section so they can be developed as a single application in its own right. Once the application has be built and tested it can be packaged up as an Element and loaded into the parent application. We’re using Ngx-build-plus to manage the build of the elements which takes a lot of the work out of creating a single bundle for the Element.

The use of NgRx is allowing us to write a cleaner code base, I know NgRx has a lot of boilerplate code, but it is a consistent pattern and if multiple developers are working on multiple parts of the application. It can lead to a lot of repeated code, bad habits can appear in the code base. Using NgRx means that if a developer picks up a different sub-section to work on they can follow along with the structure NgRx defines. This makes fixing bugs, adding new features and working out how an application works easier. We’ve all been there where we’ve take over a project written by another developer and a common question you ask yourself is ‘why have they written it like this’. Well with NgRx that’s not a question we should be asking.

It’s early days with this approach, we still need to test this further to make sure there aren’t any further issues that we may run into before we completely switch over to using Elements and NgRx, but so far I think it’s a good approach for developing large enterprise applications if you don’t want to us a monorepo approach that Nx prescribes.