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.
In my Observables in Parallel blog post I discussed how I’ve been moving away from Promises in favor of Observables and how to translate functionality from promise-based solutions to observable-based solutions. The aforementioned blog post discussed how to wait for multiple Observables to complete before performing some action. In that scenario all the Observables were independent of each other, meaning none of the Observables depended on the results of another.
In this blog post I’m going to discuss how to use Observables that do depend on a different Observable to complete before executing – AKA Cascading Observables. One such use case scenario for Cascading Observables is when you need to call a web service to get some data, then use that data to call another web service, all in a single operation.
Since observables are being heavily pushed in Angular 2 I’ve been spending some time getting acquainted with how to use them. Specifically I’ve been “translating” from a promise-based solution to an observable-based solution for certain functionality I’ve been using promises for. In this blog post I’m going to address how to utilize observables in parallel.
When I say “observables in parallel”, what I mean is multiple observables that are called all at once with the calling code waiting for all the observables to complete their respective actions before continuing. With promises you could create an array of promises, then utilize the Promise.all() function to wait until all the promises have completed before moving on. Each individual promise would utilize the .then() function to do whatever needs to be done with that promises’s results.