In the 4.3 release of Angular, there was a new HttpClient API introduced. HttpClient is an alternative to the existing Http module and exists in its own package (@angular/common/http). For any projects that are using Angular 4.x, both Http and HttpClient are supported so you don’t have to migrate to the HttpClient all at once. However, in Angular 5x, the original HttpModule is deprecated so only HttpClient is supported. Hopefully with this overview you will see that HttpClient is actually easier to use and switching from Http will simplify your http service calls. Continue reading “HTTPClient”
I had the good fortune to be able to attend the Codemash Conference again this year. Since the conference started more than 10 years ago, I have only missed it twice. As in past years, there were a number of good sessions over the four days of the conference. Over the next few weeks I will be blogging about a few of them. To start with, I want to talk about the session I attended on Chrome Dev Tools by Greg Malcolm (@gregmalcolm).
Recently, I had the opportunity to meet with a client that was in the process of deciding on a front-end technology for their dev team to use. They already did quite a bit of research and formed some opinions about different technologies, and wanted to get our opinion about the way they evaluated their options. One point I made early on in our discussion was that there is no one “right” answer to the question of “which tool(s) should we use?”. Continue reading “Choosing the Right Front End Tools”
On a recent Angular 4 project I had the need to use some custom form validations. Out of the box, Angular 4 contains validators for required, email, pattern, and min/max length, and it is possible to write your own validators as well. In particular, the custom validation I needed to do was verify that two fields were equal. For example, a form where the user enters a phone number, and then confirms the phone number in a second form field. The custom validation would verify that the two text inputs had the same value.
Most of Angular is different than Angular 1.x, but one of the idioms that stayed the same was the use of class names to identify form fields that had validation errors (e.g. ng-invalid, ng-dirty, ng-touched etc). By checking for different combinations of these classes, you can tell which fields are invalid, have been modified (“ng-dirty”), and had focus at some point (“ng-touched”). However, this had a tendency to lead to some rather verbose and messy view code just to show/hide a validation message:
Last week, Google released the newest version of their Angular framework, Angular 4.0. The biggest changes seem to be around creating smaller builds and faster code. Our Solutions Group has several Angular 2 applications in production that we have already upgraded to Angular 4, and I am happy to report that the upgrade was smooth in each case.
If you are wondering if upgrading to Angular 4 is a good idea, I have put together a list of potential questions to help you decide.
Last Friday (3/24) the Angular CLI was released as version 1.0. Our team has been using the CLI for production Angular applications since last August. As the numerous beta and RC versions were released we would update our applications accordingly. There were a few bumps along the way when a new release introduced a breaking change, but for the most part the upgrade path was pretty smooth.
I actually wrote about the Angular CLI a few months ago when it was still in beta. Now that the CLI has reached 1.0 status, I thought it would be a good time to review how we are using the CLI, and what we see as the main benefits.