I recently reviewed some Angular code that uses one module. The AppModule. To manage the entire code base. And, this isn’t tiny code base. The main excuse I’ve heard for this is that the code originated during the beta cycle, prior to NgModule being added to the framework. I call it out as an excuse because once it was added, it was clear that we needed to have more than one module. The fact that this code base doesn’t have more than one module shows a disregard for doing things right over doing things fast. In the best case, it shows ignorance.
But, the larger question this code base raises for me is this: “Why are more modules better than fewer modules?” After all, using one module obviously works. Isn’t the fact that it works sufficient enough?
And here are three really good reasons to use more modules.
This past week I had my first need to do use cross field validation in Angular. While the general mechanics are pretty trivial, my particular implementation ran into some issues that you might be interested in.
We all know about best practices. But what does it take to really mess up a project? Well, for starters, you do EVERYTHING wrong. You don’t just ignore one or two best practices, you ignore them all. By evaluating the mess you can get yourself into by ignoring best practices, I think we can all learn better why these recommendations exist.
As you might have noticed from last week’s post, I’ve shifted my focus from pure Angular to learning Angular Ionic. And while last week’s post focused more on just getting Ionic setup on a Windows environment, this post will focus more on integrating Ionic and Angular CLI to work together.
If you are familiar with Ionic, you should already know that it provides its own CLI that allows you to scaffold out a new application using a basic template. This CLI is also used to help register the project with the Ionic Dashboard and scaffold out a limited number of file types if you use Ionic 3. However, there are several problems I have with using the Ionic CLI. First, and probably most important to me, is there is no test scaffolding! Second, it neither follows the standard naming convention for files nor does it comply with the Angular Style Guide when it comes to directory structure.
My first attempt at correcting the problem was to try to add Ionic to an existing Angular CLI project. I almost had that working, but I got stuck trying to get the SCSS implementation working. I finally gave up once I realized that Ionic seems to load files on demand, including SCSS files and templates. I might come back to this once I’ve gained more experience with Ionic and have a better idea of how it works under the hood.
So, my second thought was to just add the Angular CLI to an existing Ionic CLI project. It turns out this was much easier to get working. This allows me to use the standard ng commands to scaffold out my components, services, interfaces, etc… and because I’m using the Angular CLI scaffolding, the tests also get scaffold out for me.
While testing Components is possible, it is not easy and is often pointless. Using the Model View Presenter pattern, or a variation of it, solves the problem.
Here’s the deal. Long time readers of my blog know I’ve been a proponent of Unit Testing for a very long time. While I was learning React, I went through the exercise of trying to write test as I was learning. Now, the great thing about Angular and React is that it is possible to test your components. The problem with testing components is that you are either testing that your HTML ended up in the right spot, that Angular directives did what they should, or you are evaluating the DOM to verify that component logic worked. In most cases, putting tests that do any of these at the component level is the wrong way to test.