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.
This past week I took Angular Material for a spin. In the process, I learned a few things you might find helpful. Some may be helpful even if you aren’t interested in using Angular Material for your projects.
There seems to be a lot of confusion about Implement NgRX 4 in an Angular application. Some of it I’ve contributed to because NgRX 2 isn’t quite the same as NgRX 4 and as I’ve transitioned, I’ve learned better ways. In other words, I was wrong and I’m correcting my mistake! Below is the correct, NgRX approved way, of implementing NgRX 4.
If you are looking for information about how to convert to NgRX 4 from NgRX 2, you can visit my previous article, How to Upgrade to NgRX 4.
Before we get started, make sure you have TypeScript 2.4.x or above installed in your local project. The CLI may complain, depending on what version of it you are using. But, NgRX 4 requires us to use TypeScript 2.4.x. You should also have RxJS 5.4.x or above installed.
You will also need to install @ngrx. You can do this using the following NPM command:
npm install --save @ngrx/store @ngrx/effects
And finally, I’ve found that I need to use the –aot switch both when I’m using production and development builds, so you’ll want to add that to your scripts in your
When NgRX 4 came out and I discovered that the “right” way of creating Actions is to use TypeScript classes and not Object Literals, I was a bit surprised. Why would you use a Class that requires you to use the “new” keyword? Why would you put multiple classes in one file? This is insane!