Our company often does Angular projects so I’ve done a number of Angular 4 projects already and, currently, it’s a love/hate relationship. I wanted to try React so I wrote a side-project that uses React with Redux. This is my high-level comparison between the two.
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.
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.
The front-end testing I’ve done in the past has always had some friction with respect to getting the tools setup properly. Mostly I have used Jasmine as the testing framework, which is pretty self contained – but to get a node test server setup properly there are a variety of other npm modules and karma configuration settings to deal with. I previously wrote about how the angular-cli makes it easy to get an Angular 2 project setup, and this includes getting the test tools setup as well. So instead of dealing with configuration settings, you can quickly get to just writing tests.