comment 0

Managing complexity of Angular applications

Let’s say you are a newcomer to modern front-end development and you need to implement a single page application. You already know HTML, CSS, and some JavaScript. You have heard that Angular is a solid framework and you like the fact that it is based on OOP principles you are familiar with. So you start learning it by taking an online course teaching its basics while at the same time reading the official documentation in order to explore various building blocks in more detail.

After a while, you feel quite comfortable using the framework and you decide to start building your application. Since you are a newbie in this area, you try to follow Angular Style Guide to avoid bad architectural decisions right at the beginning. You build small reusable components and fetch data from the API in singleton services as you have been taught. You are making a good progress, creating a lot of components and seeing the first results on a few screens of a really nice user interface you have already built.

But you feel that something is fundamentally wrong with your application. It is still quite small but there is already a huge complexity when it comes to interactions between components and data management. You have figured out how to avoid redundant API calls by remembering the data needed by multiple components but your adhoc solution seems to be a little bit messy and error-prone. You need to be very careful not to introduce a bug when extending some functionality. It is already such a pain developing this application and you cannot image how it will look like if it grows ten times or more.

The problem is that neither the online course nor the official documentation has taught you how to manage the application state. They have only introduced various Angular concepts such as services which they recommend for data sharing between components. But once your application starts growing, using services to manage its state is a way to hell.

Fortunately, there is a whole set of state management libraries that try to solve this problem. The most popular is Redux which is mostly used by React developers although it can be used with Angular as well. There are also some libraries designed especially for Angular such as NgRxNGXS, or Akita which are based on RxJS so you can keep using observables that you are already familiar with. I would recommend using NgRx as it is the most popular one among Angular developers. But feel free to try out more of them and choose the one that best fits your use cases.

I am not going to explain the concepts of FLUX architecture these libraries are based on as many others have already covered this topic quite well. What I wanted you to know is that you have encountered a common problem in front-end development that have already been solved by people much smarter than you (no offense). So there is no need to implement your own solution or hack your application until it becomes unmaintainable. Using a robust state management solution is the only way forward if your application is going to grow significantly.

Leave a Reply

Your email address will not be published. Required fields are marked *


This site uses Akismet to reduce spam. Learn how your comment data is processed.