Tag: Angular

Writing Maintable Angular

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.

Here is a link to my slides from the talk.

What painting a shed can teach us about writing software

What can we learn from painting

With the world being on lockdown I recently had time to finally get around to painting my garden shed. It’s a job that I kept putting off because I wanted to do other things (like playing Ghost Recon Breakpoint).

Anyway, I finally started to paint my shed and as I worked away on painting the shed, I thought to myself how we approach something like painting a shed can be job could be applied to software development.

Thinking about it there are five rules that you need to apply to paint that also applies to software development. These rules are:

  1. Always prep before starting
  2. Have the right tools
  3. Plan before starting work
  4. Don’t move on to working on a new section until you’ve finished what you started
  5. Practice makes perfect, well better

Always prep before starting

Before starting any project you have to prep. For painting a shed, you have to make sure the shed has been swept, removing all dust and dirt. Then you have to smooth down any splinters or rough edges and then make sure you have planned how you are going to tackle the work ahead.

Have the right tools

If you start trying to paint a shed with a small paintbrush, one that you’d use for painting a small picture. That would take you ages, and after a while, the brush would be useless through it not being the right tool for the job ahead.

The same can be said for the tools you use to build your software. In the Angular world we have tools like the Angular CLI, Karma for tests, WebStorm for writing your code. You can write an Angular application using Notepad, by why would you. Use tools that not only help you write code, but enable you to write the best code you can.

Plan before starting work

I’m not the best painter in the world so I need to spend a bit of time before throwing paint at a shed I need to make sure I’ve spent a bit of time planning what I was going to do.

So Ive learnt of the last few attempts at decorating that it I need to put in some planning before getting started. This involves working out what part of the shed I was going to paint, where I was going to start and what section of the wall I was going to paint.

Having a good plan for what I was going to do before getting started helped me do a better job this time than I had before.

This planning before you get started on a piece of work should be applied to development as well. Whenever you’re about to start a new feature or implement a new section of an application, spending a bit of time planning what you’re going to do before diving straight into the work is always recommend.

This planning , even spending a few short minutes thinking about how you’re going to tackle the problem in front of you, will save you so much time and probably lead to better written code.

Don’t move on to working on a new section until you’ve finished what you started

One thing I decided to do this time was to paint the shed section by section. This way I could keep track of where I’ve painted and move from section to section once a section had been completed.

Again this approach can be applied to development as well. When building a new application, it can be easy to start on one part of the application then quickly move on to the next, just to get the basics of the app setup. To give you the impression that you’ve got a lot of the application up and running, but this is not a great idea. Say you have a target of having 80% of unit test coverage for your app, but you’ve gone off creating screens, adding services and setting up routes. You’ve done all this work and no tests. Now you have to go back to where you started and try adding tests. But in your rush to get a lot ‘done’ you’ve written code that is hard to test!! So now what do you do, spend more time trying to work out how to write tests for code that is hard to test. All that time you think you’ve saved get all these sections done, now you have to spend more time trying to setup tests.

So it’s worth making sure that you have the section your working on completed before going on to the next feature. Yes, from a project perspective it can look like you’re getting a lot done. Your sprint tickets are being moved into In Progress and Done really quickly, but is the quality of the work you’ve done that good? Making sure you’ve finished to a decent level a section or feature of the app before moving on to the next will save time in the long run and the quality of the work you do as a developer is more impressive than moving tickets on a sprint board.

Practice makes perfect, well better

Finally, the thing I did learn while painting my shed was, while I don’t paint sheds as a living I did notice that this time I was doing a better job than the last time. Each time I had to do some decorating at home, it was a perfect opportunity to practice my painting skills and the more times I did this the better I got.

Now I admit my painting skills are not great, but that shouldn’t stop me from trying. The more times I try, the more times I could practice and through this I was getting better.

The same can be applied to web development, the first website or web application you build won’t be perfect, but only through trying over and over will you get better at writing good quality apps. It’s better to keep practicing and trying this leads you to learning new and better ways of tackling problems. Leading to better apps for your users.

A great book on this idea of practising and getting through this barrier of thinking that you’re working isn’t good enough is Steven Pressfield’s book The War of Art where he talks about the resistance we feel putting our work out there, but through getting through this resistance and keep putting work out will we get better at our work.

So while I’m not a great painter and decorator, though taking my time, working bit by bit, using the right tools for the job and not putting off getting the work done. I’ve managed to do a decent job on my shed. Taking this approach can also lead to good quality code, leading to good quality applications.

Working with legacy apps

Angular 11 has just been released, over the last few years, Angular has gone from version 2 to 11 its growth is amazing, and with each release, there are new features and new ways of working with Angular.

While this is great and shows that Angular is still a vibrant framework, it does mean that having a long term Angular app needs to be closely maintained. Version numbers need to up upgraded, test coverage needs to be maintained, there is a lot of work involved in managing legacy Angular apps.

What is a legacy app?

For me, a legacy app is one that cannot be easily maintained. Where the code base is structured in such a way that it takes a new developer on the project a few weeks to feel comfortable in being able to add new features to the app. Where the application structure doesn’t follow any industry standards and where it takes a series of steps to just get the app running locally.

With applications like this, not being able to add new features or upgrade the underlying technology that is running them means that eventually, the client will begin to resent the application that use to make their work so much easier. They become a drain on the clients time where they have to find ways around the problems the old legacy application is giving them.

How can legacy apps be improved

Not all is lost with legacy apps, there are ways to bring them back to what they were. It just takes time, effort and clear understanding with the client that things may seem to get worse for a short while but soon the application they use every day will be better.

What steps can a team take to update a legacy Angular application?

The steps that a team can take when upgrading a legacy Angular application, they are:

  1. Have Unit Tests – tests help by making sure any code changes have not broken other parts of the application. As the code is upgraded, or versions of packages are updated tests can be run to show these changes have not had adverse effects on other parts of the app.
  2. Have UI tests – these tests can be used to show how the app works for the end-user. Even if you have a legacy app that doesn’t have any end to end tests, tools like Cypress are so powerful now, it makes writing end to end tests easier. Having tests like this in place before making changes to a legacy app is a good idea so these tests can be run to check that the app still works as it did before.
  3. Use Angular Elements to upgrade an app in stages – if you have an AngularJS application that can’t be re-written in one large go. Angular Elements are a great way to improve parts of an application in stages. Angular Elements are complete Angular (not AngularJS) applications that can run within AngularJS application (this is a method I used to upgrade parts of a large app for a major organisation. We wrote new parts of the app as a standalone Angular app, then converted it to an Angular Element and loaded that in the original legacy AngularJS app. To the user, there was no visual difference, but to use as development team, we could use this method to upgrade the entire app, bit by bit.
  4. Agree to use an industry standard to how to structure any new parts of your application – if you are going to upgrade your legacy Angular application to the latest version, either through the use of Angular Elements or through a gradual re-write. Then agreeing to use an industry-standard approach to how to structure the update application is an excellent idea. For example, you decide to use an approach like adopting NgRx as the way you are going to structure your Angular app, you’ll find that the developers on your team will enjoy working with a standard approach to developing the application. There would be more resources for them to make use of when looking for the best practice approach to solving a problem. They will enjoy developing an application they know that the new skillset they are learning can be used elsewhere in the industry and an employer it will be easier to get new developers on a project up to speed to be able to work on the project if it follows a well known standard approach.

Our app sounds like a legacy Angular app, what can we do?

If your team is struggling with a legacy Angular all is not lost. You can improve it without completely scrapping it and starting again. It just takes investment by both the development team and the end-user in believing that things may be hard to work with for a bit, but through using some or all of the ideas I’ve listed above. The application can be turned around from an old legacy application that is slow and hardly has any new features. To a much faster, useful application, where new features can be added in just a few weeks instead of months. Making both the developers of the project and end users happier.

If you feel that you need an Angular expert to help you with your legacy Angular app, then feel free to contact me.

Thinking in Redux – a Review

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.

Agile doesn’t work if your code isn’t

I’ve worked on a few software projects over the years and many of them have been run within an Agile environment.

Agile is a software planning methodology where the work is carried out in small chunks, the requirements are listed in a backlog, which is worked on through these small chunks of development time, called sprints. At the end of a sprint a piece or pieces of work are delivered. This allows software teams to move quickly through the software requirements, be able to deliver software quickly and be able to handle changes in requirements as they go, become agile in the direction they move forward

This is the general theory, unfortunately from what I’ve seen over the years teams that have a Agile project management methodology, but who’s software is still built using a pre-Agile approach struggle to deliver what Agile promises.

The reasons for this are, if your software architecture is still very closely coupled, meaning one layer (the front-end) can not be fully developed in separation from the backend. It is extremely hard for the developers to make quick, fast changes because they run into numerous issues. They may have to wait for the backend team to make a change to an API in order to provide data that the front end needs, if there is no tests in place there isn’t the time for tests to be added or new tests to be written. This can lead to bugs coming into already delivered software and as the team moves forward in their Agile way, the time available to fix bugs and write tests gets less and less, leading to the possibility of the bug list growing and growing.

Implementing an Agile software project management approach is far easier than moving an large enterprise application to being able to be worked on in an Agile way. Arranging two week sprints, setting up a task list board and having a backlog and your ready to go is far easier than getting your software setup to be Agile, but it is possible.

The key to solving these problems is moving the architecture of the project to a more separated approach. Where each layer can be developed on independently, and doesn’t rely on another layer having a new piece of functionality in place before work can start on a new feature.

Dividing the work in a sprint between delivering features and updating the architecture of the application to be more separated allows, over time, the project to become more in line with an Agile approach. The developers can amend the application so the front end can run in separation from the backend. The UI layer can be written in separation from the front-end layer, allowing the UI to be mocked to show users how new features could look so feedback can be given earlier in the process. Leading the feedback being added into the sprints work load before all the other layers have implemented a feature.

Modern web tools can help

Using more modern web frameworks and tools can help. Using something like Angular to build just the front-end Logic, while the UI is built by another developer. This UI can be what is demonstrated to the end user in sprint planning when gathering requirements so the entire team knows what is expected. Using frameworks like NgRx and Nx workspaces allow the Angular developers to move the Angular code add to a consistent pattern that all the Angular developers on the team can follow, leading to a consistent structure allowing any of the Angular developers to work on any part of the application (especially if this is a large enterprise application) without much ramp up time. This can be extremely beneficial for distributed teams or teams with offshore developers.

Tools like NestJS or Node can allow the front-end team write mock endpoints which they can use to build from, while the backend team works on the real production ready APIs.

If the structure of the response is agreed upon, in sprint planning, then the mock APIs (which could return static Json) should be fine to get started building against.

Agile Can Work

Agile can really work as a way of managing the workload of a team, but without an architecture that can support quick code changes bugs will linger and more and more time will need to be spent on fixing issues.

An agile project management approach with a flexible approach to the codes structure will lead to applications that can be delivered quickly.

I like the Agile methodology, but we need to consider the structure of our existing code before going head first to a fully agile approach.

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.

Reactive Programming, a shift in mindset

Photo by Jens Johnsson on Unsplash

As part of my upcoming book Getting Started With Angular 8, I spent a time researching Observables and RxJs in Angular. In the book I spend a complete chapter going through how Observables work and how RxJs is a JavaScript library that comes with Angular, which helps with working with Observables.

While this chapter gives a detailed explanation of using Observables and Observers, how you use them within your Angular applications.

One thing I have noticed now within the Angular community, there are more and more talks and articles about how to make use of Observables and RxJs to create fully reactive applications.

Now developers are beginning to understand what Observables are and what RxJs brings to their applications, the next question is how can we make use of this to the benefit of our applications? More and more community leaders are showing ways we can use RxJs to make applications more reactive.

Changing the mindset from imperative to reactive

In the Observables and RxJs chapter of the book I go through how to use and Observable with RxJs, but the approach I use is a more imperative approach. Where we create and Observable, set it up and then Subscribe to the Observable when we want to make use of it.
Now after seeing some fantastic talks from NgConf about how we can make use of RxJs to turn how we setup our Observables to make the way data is passed throughout the application more reactive.

Some of the great talks that show this new approach are:

  • Data Composition with RxJs – in this talk Deborah Kurata show a pattern for creating streams of data with RxJs to generate a View Model behind our components. Models that load data via Observables that don’t need to be subscribed to.
  • Mastering the Subject: Communication Options in RxJs – in this talk Dan Walhin shows how we can use the Subject observables to pass data or messages to multiple components within our application.
  • Thinking Reactively – Mike Pearson goes through why thinking in a more reactive approach is a great idea. He makes some fantastic points about why taking this reactive approach will benefit our applications.

Having a more reactive mindset means we use patterns to structure how data is passed into and out of our components, so the application reacts to changes from the user. Building applications this way makes our apps appear faster and more responsive to the user. A fast acting application makes a happy end-user.

As Angular developers I think we should start sharing different approaches to how we can write more reactive Angular applications. If we look at sources from outside Angular, like existing patterns which may not be used currently in this imperative approach. These patterns will help us develop in a more reactive mindset.

These talks are a great starting place if you want to start take your knowledge of Observables and RxJs and how they can be used to making a more reactive application. If you’re not sure how to use Observables and RxJs then feel free to check the chapter in my upcoming book.

Angular and Nest idea for fullstack apps

Photo by Steve Halama on Unsplash

I’ve recently worked on a project where we found ourselves in the situation where we was waiting for some APIs to be developed by the backend team. So in order to not stop our development we decided to look at creating mock APIs.

Now there are many online services that can provide you with a mock end point to work with, but there are limitations with the number of endpoints you can make or the structure of the data you can return.

So we decided to take a look at using NestJS in order to create our mock APIs. First impressions were really positive, as an Angular developer I found getting started with Nest very easy. With Nest using similar concepts to Angular (Services, Modules etc) I found Nest a great way of adding a backend to my Angular application, Nest is something I plan to look at further.

I can see that there will be two approaches to creating a fullstack application, one approach seems to be ReactJS with Node/Express and the second approach is Angular and Nest. If you look at the job market you’ll see a lot of roles where the tech stack is React and Node in order to create a complete fullstack application. Now with Nest becoming more and more popular I can see Angular and Nest becoming a tech stack for creating a fullstack application.

If we look at how Nrwl are developing enterprise applications they are taking this approach of using Angular with Nest as their stack for their clients. As a side note when we decided to create our mock APIs we was using Nrwl’s Nx service, which makes managing the setup of a complete Angular/Nest application so easy and with the addition of Cypress it makes a fantastic complete approach to creating a full stack application.

As an Angular developer I would recommend that any Angular developers look at using Nest even if the applications they build are using APIs created in another language by another team within their organisation. The reason I think we should look at Nest is because if, like I did in this application, you have to wait for the ‘real’ APIs to be ready you could use Nest to create a mock APIs.

Eventually I can see the Angular/Nest approach becoming a standard way of building fullstack applications, which is something I’m planning to work on while I’m between projects.

Turning Design into Angular Components

Recently I had to take a design and create the Angular components for this design, while working through this problem it made me think about the thought process of how as Angular developers we turn designs into working applications.

When I first looked at the design, it’s a very simple layout of a page, which has a simple form, and a few controls at the bottom of the page. The first thing I thought of was how I would divide up the sections of the page into separate components. I’d create one component for the main page, one for the form, one for the controls at the bottom of the form, then off I went creating components using the CLI.

What I really should have done is looked at the page as a whole, how it works within the application and asked myself some questions before diving into building components.

The types of questions to ask before include:

  • What is the purpose of the page, what does it do?
  • What are the inputs and outputs of the page?
  • How will the possible components of the page pass data to other components?
  • Is there already a component I can reuse for this design?
  • What is the teams conventions on how pages should be built? Do they have a preferred way that components should share data?
  • Is this design actually finalised? If it changes is my approach flexible enough to cope, so if the design does change is there a large amount of work to change the page?

These questions are important, because we need to plan how we are going to build out the pages/views of the applications we build.

There can be times when we as developers are given a design to implement and it at first glance looks so complex that we are not sure where to start, but I think there are a few points we should remember in order to get started.

  1. Iteration – the first attempt doesn’t have to be perfect, you can always iterate on the implementation
  2. Feedback from others – getting feedback from others is important to get their perspective, but you still have to use you original ideas as starting point
  3. There is no perfect way – there are many different ways to create a layout from a design, there are best practices (for efficiency and performance) but trying to hit that perfect approach first time is impossible

Angular is great, it gives us so much out of the box, but it is too easy to just start throwing out components using the Angular CLI, that this few minutes planning of how to turn a design into a set of components can be missed, which may lead to problems later.