As mentioned in the previous blog post, I will continue with my remarks about some Angular 4 design choices, similar to what I did in the previous one. The course I followed was very in-depth about Angular 4, but there may still be things I do not know. I am not an expert in Angular 4, and my real life experience with Angular is very limited. I am aware that this may influence my opinion and cause me to dislike certain choices while better ways to do it exist. I am open to this, and please let me know if you have any comments or advise for me.
|Old Name||New Name|
Angular forces a clear distinction between the data (stored in Components) and the visualisation (the HTML file), which I really like. But since Angular uses TypeScript, you would gain a lot by using the type system. While this is possible by having regular classes, I often don’t feel that using them would give you any benefits. Although I prefer strict Object-Oriented design, putting objects into classes rather than components doesn’t seem to be a good design in Angular. Mostly because the HTML page needs to be able to access the data to show, and since the HTML page is linked to the component, it makes more sense to have the data stored in the component rather than in a separate class.
The clear separation is however sometimes broken, and a good example of this is the existence of the @ViewChild annotation. This links the Component to an element in the HTML page, which means that the component needs to know the HTML page and thus have knowledge about how the information is shown. For me this is a bad design and I never use this approach. Another way the separation is broken is when you create Forms, both ways of creating forms couple the representation with the actual data. Forms however are a very difficult case because it solely consists of a field key and a value and somehow you need to link these two together. The data has a member where the name indicates the key, and the value the actual value. The form however has a label to represent the key and an input field for the value. The easiest way to break the tight coupling is to use two-way property binding on all fields but this feels like overkill.
The usage of ngIf is a handy way to show parts of the page only if a certain condition is true. The ngIf however also has an else clause, similar to how it works in programming languages. But unlike programming languages, the else clauses is a different part of the document and marking this part is cumbersome. You end up with an if on one element with an else clause referring to a completely different element. This means that the element itself is now no longer responsible for deciding when to be shown, which may cause debugging to be harder. For that reason I never use the else clause, but always put an inverse if statement on the other part. This makes the document easier to read and understand, also for people who are not that deep into Angular.
As a Software Engineer I am very eager and strict on writing tests for the code I write. Angular is no exception to this, but as I wanted to write tests I quickly discovered that it was not that easy and a lot of boilerplate is required to stub all dependencies. I had a lot of problems because I was using Angular Material design, which means all of my pages contain other components that need to be imported for each test case. I found it too much effort for the small gains it would give me, that I just gave up and didn’t test my application at all.
A final remark is about documentation, which I feel is sometimes lacking. I have often found myself where I was looking for something and could only found results for AngularJS. Moreover the documentation on Angular.io is sometimes completely missing as well. To me, this is a clear sign that Angular is not stabilised yet, but nevertheless when creating such a framework, documentation is key.