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.
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.
I’ve noticed a pattern in the programming world at large both with programmers and with managers. We define things how we want them to be for our organization and not how they are. We are like Humpty Dumpty who says, “When I use a word … it means just what I choose it to mean – neither more nor less.”
There are two places where I see this pattern manifesting. The Agile movement and Design Patterns.
It is not uncommon in our programming endeavors to need to replace one element in an array. Using old school procedural programming, this would be relatively easy. Loop through the elements, when we find the one we want to replace, change the value. Basic for/next loop with a conditional statement.
But when you move to a more functional way of programming as we need to do for NgRX, or are encouraged to do to make our code more testable, the problem becomes less straight forward.
The initial solution you might try would be to just run reduce()
against the array. But if we do this, we still need to put that nasty conditional within our reducer function. This is something we’d prefer to avoid. Yes, it will work. But it isn’t Functional. This problem has bothered me for months. I’ve finally spent the time to figure out the solution.
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.
Then, 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.
I started playing with IONIC last week. Since I do all my development on a Windows computer, this has already lead to a particular Windows based challenge that I was able to track down and deduce the solution for. But I was unable to find a solution that specifically addressed using IONIC, putty SSH, and authorized_keys Format, which is what someone is likely to search for when they see this issue.
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 and above 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:
1 | 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 package.json
file.
Since I don’t seem to have a blogs worth of any one topic to write about, I thought maybe something more along the lines of a cluster of small tips and tricks might work. Since I’ve been writing my Angular book over the last couple of weeks, there hasn’t been much new that I’ve discovered worth sharing. But there are a few small discoveries I’ve made. This week, they center around NgRX Effects.
For the last 18 months, I’ve been working for an organization that has what some might consider a unique requirement. Because of where our application’s data is sourced, we need to aggregate data on the client side rather than on the server. What this means is that for any one screen, we may make multiple calls to the server to grab all the data we need. Fortunately, because we adopted NgRX early in our adoption of Angular, we could avoid a lot of the headaches associated with client-side aggregation.