I’ve recently given my first talk on the great NgHuston YouTube channel, the topic of my talk was ‘Writing Maintain Code in Angular’.
The main idea of my talk is how we can structure our Angular code in order to make it maintainable for the long term use of the application. In the talk I go through two example apps, both with the same functionality, a book search app, but in the code I’ve tried to show how you set out your folders and components, lead to more maintainable code. That as the application grows it it easier to add new features and maintain when bugs arise.
If you want to see a video of my talk you can, here’s a link to the recording of my talk .
The main points of my talk
In the talk I tried to put across a series of points that are important in writing maintainable Angular code. These points are:
Make use of modules to structure your code into small sections
Use descriptive property names and function names
Make use of methods to write more descriptive code
Use Types to create a domain specific language describing the data of the application
Write tests that allow you to refactor your code to make it more maintainable
Refactor as you go, keeping the code tidy, manageable and readable
In the talk I expanded on these points and try to show through the code examples how to write the example code so it is more maintainable over time.
I recently finished reading a great book all about Redux, which is the core pattern behind NgRx. The book is called Thinking In Redux by Nir Kaufman. In this book Nir goes through introducing the core concepts behind Redux, including Actions, Reducers and Middleware (which we call Effects in NgRx).
As Nir goes through the book not only does he explain really clearly what each of the core concepts are, but he goes through and breaks down each concept into subsections. For examples, Middlewares are divided in to different categories one for Core functionality, where the Middleware role is to handle a common piece of functionality that could be used over and over again within the Application, e.g handling an API request. Verses a middleware who’s role is to handle Routing Actions.
The book is divided into 8 main sections, the first section is about how to think using the Redux pattern. It’s a great introduction into Redux, it’s core concepts and how we can think about these concepts as we start planning the development of our apps.
The second section is all about Actions, what they are, how we should use them, how to program an application using this pattern and ways we can categories the different types of Actions we may have in a Redux application.
Then Nir moves on to patterns for routing Actions and transforming Actions, how we can use Middlewares/Effects and various approaches we can take when writing our middleware/Effects.
In the final sectionNir goes through some thoughts on a Redux project structure, naming conventions and some recommended reading. While in the NgRx world we have the naming convention set out for us, his ideas on project structure are interesting.
On the whole Thinking in Redux is a good book. It explains the main concepts and patterns behind Redux really well, it’s a short book so doesn’t take long to read. I would recommend it to anyone looking to understand Redux a bit better especially if you’ve just started using NgRx for your Angular application and you want to take your understanding of Redux a bit further.
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.
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.
