How to Best Manage Angular State
When working with Angular, it is very easy to fall into a trap of managing state. This is a hard challenge because Angular on its own does not ship with a working solution. Therefore you have to implement this logic yourself.
A common approach is to use one of the solutions out there like: Akita, NGRX or NGXS. I think that each of these are great pieces of software — each one of them having their flavour to it.
This is not an article comparing these tools. For simple case, you can do pretty ok using Subjects in RxJS.
The topic of this mini series is to focus on architectural principles of managing state in angular and how to achieve high cohesive and low coupling system that helps you to glue User Interface and Domain layers via Application Layer.
For the sake of this exercise I will use RxJS (to keep it simple).
Are you ready? So fasten your seatbelts!
Component managing State Anti-Pattern
Smart Components are pretty common places to write your state logic. It makes it makes them re-usable and it seems to be a logical place to do it. However as application grows, your Smart Components will grow as well. This always leads to Smart Components bloated with logic and becomes a burden for developer to maintain. If you do not follow TDD practice and do not refactor your code often, it is very easy to fall into a trap of cowboy coding — just to make a feature done :)
Be aware of it and keep your Smart Components clean!
Service managing State Anti-Pattern
Another convenient place to stash your state logic are services. This is popular for many reasons like: re-usable logic, it makes it easy to communicate between different components and it seems pretty logical.
In case where there are multiple components that want to get the same data, injecting the state logic in a service seems logical, however it comes with price which is unacceptable when dealing with enterprise level app. The cons simply out-weight the benefits:
- Single Responsibility Principle violation — what is a service then? does service get the data? does a service manage state? does it do both of these things? what is my name then? :) you quickly start to question even most fundamental concepts :)
- Maintainability — when the use case is simple and you only have 1 model being returned, then you might get away with this crime :) but as soon as you start returning multiple objects that are related to each other for multiple clients (a.k.a Smart Components), you will quickly make a lot of lines of code to achieve simple stuff
- Flexibility — with more scenarios, you will overcomplicate your code and use multiple subscriptions / tap / switchMap and other operators in order to do simple data extraction.
- Crossing Boundaries of Bounded Context — it is so easy to start calling another services or simply expand your object to fit one more case and soon you will have to deal with code smells like: God Class, Spaghetti Code, etc.
TLDR: How to make State manager in Angular using Test Driven Development?
Conclusion
Add a new layer to your code that will represent access to your domain logics and will use infrastructure layer in order to facilitate communication with backend / local storage.
