Month: September 2019

Thoughts on NgRx

I’ve been using NgRx for a short while now and I thought I’d write up some of my initial thoughts on it.

Getting started can be tricky, it is a steep learning curve, but once you understand what each part of the framework is for and the underlying approach NgRx is taking a then it’s easy to get going.

One complaint about NgRx is the amount of code you have to write, the number of files you have to generate in order to get something working. For me I don’t think this is such a problem with file is designed to do one thing and one thing only. This separation of concerns makes reading through an NgRx based code base easy to understand. When you open one of these files, a reducer for example, you know exactly what that files role is, what is does and how it works. It’s just concerned with the one thing and shouldn’t have any other unrelated functionality in that file.

With today’s modern editors it makes switching between files so much easier and faster. If you had to use Eclipse to write NgRx you would definitely have a case to complain about the number of files.

One of the things I really like about using NgRx is this prescriptive approach it takes. As a contractor I have to work with a new code base every few months and being able to ‘get up to speed’ with how an application works can take a while. Even though they are all Angular applications, I find that there are 100s of ways an Angular application can be structured, based on the needs of the business or the experience of the developers who have worked on the app.

If an application has a good developer, who thinks about and plans how to write their code, and a business who are concerned with the quality of the product over just getting things done. A applications codevase can be well structured without NgRx, but through using a framework like this means that the code is well written and based on good practices.

So when someone like me starts working on the project I can go through the application and see how data is passed through the app, how actions are being used and when and how the application flows.

So I’m enjoying using NgRx , it definitely has its place, in developing large scale applications, with a team of developers working on the application for other projects NgRx isn’t the best approach, but for a large application it’s a great choice of framework.

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.

What’s been happening at CGCSoftware

We’re into September now and I thought I’d give a small update on what’s been happening behind the scenes at CGCSoftware towers.

The main thing that has happened is I’ve started a new contract working for Cambridge Assessment. Working in one of their teams on a large scale Angular application. It’s an interesting project working with NgRx and Angular Elements to create a more loosely coupled application allowing different developers work on individual sections of the application, but still access the APIs that run the application in a consistent way.

I’m finding working with Angular Elements really interesting, they have real scope to give so much more flexibility in how Angular applications can be set up. Not only are they great for gradually upgrading an AngularJS application to Angular. They allow teams to create individual parts of a large scale application in separate pieces which can be slotted together in the main application.

The second big thing that has happened is that my book, Getting Started With Angular 8, has been released.

Writing a book has been a massive project, it’s taken far longer than I thought it would, but I’ve learnt so much through writing the book.

Not only have I learnt more about Angular, but how to create content for the book. Originally you think that it’s just a simple case of writing out you thoughts on the topic of the book (in this case Angular) but there is so much more that you need to think about. How to structure the chapters, how to make sure the reader is left feeling that they have learnt something, how a section you felt made sense when you originally wrote it, didn’t make sense at all.

Having published the book through Leanpub I can make further updates to the book as newer versions of Angular come out or new features are added.

So August has been busy, I did manage to get a holiday in as well, which was great. Now we’re into September and got another busy month ahead. Looking to work some more with NgRx, while still getting up to speed with how things work at the new contract. Also looking at ways to be involved in some more open source projects in the coming months.