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.
I ran into a scenario the other day in an Angular 2 app I am working on where I needed to show the same page/route, but with different data and parameters. Without getting into the specifics of my app, the scenario was analogous to this:
I am viewing a page that shows customer contact details. The route pattern could be something like “/customers/:customerId/contact/:contactId”. On the customer contact detail page, we also show a list of links for other contacts with the same customer.
Last week, I mentioned I would be leading a Lunch and Learn for our colleagues at Total Quality Logistics (TQL). We’ve been working with Angular 2 since August 2016, so we have a fair amount of experience with it and want to share our knowledge with other members of the tech community.
The presentation went great—we had well over 50 people in attendance! As attendees munched on IBS-provided sub sandwiches, I spoke about what’s new with Angular 2.