I’ve talked around NgRX several times over the last few months but I’ve yet to write an article on how to use NgRX. This is because I was under the impression that there were better articles available. And while there are a lot of articles available, there is not anything I feel comfortable sending another programmer to who is trying to learn NgRX.
So, rather than spend a lot of time on why you want to learn NgRX, or arguing against some of the unfounded hesitations, today I’m just going to dive into how to use NgRX.
On the subject of Angular2 Architecture, the perception is that Angular 2 is a highly-opinionated architecture. But even though there is a style guide for Angular 2, there are a lot of decisions that still need to be made when working on any but the most trivial of applications. And even then, since most applications take on a life of their own, one could make the case that you need to make these decisions for any application you are building regardless of the initial size. Applications grow up. But, that’s another blog post.
I’ve identified, and have formed opinions about 5 areas that Angular 2 leaves open for decisions. Areas that if you don’t spend time considering the choices and making decisions could cost you in the future.
Last week I wrote a post that talked about Unit Testing and the need to make sure you are only testing one particular unit of code at a time. The post was well received. But I am surprised that no one commented on the glaring hole I left in the post.