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.
Continue reading “Cascading Observables”
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.
Continue reading “Observables in Parallel”
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.
Continue reading “Angular 2 – Testing”
A quick warning to those using the tag in their Angular 2 app: Don’t do it inside of a template (including conditional blocks, such as an *ngIf).
I was working on an Angular 2 application that allowed the user to select an item to view details for. At the top of the details page I wanted to show some general details about the selected item, and the main body of the page would basically be a set of tabs to show different information based on the selected tab. For example, when viewing information about a user I wanted to always show general information about the user at the top of the page (stuff like first and last name, username, user id, etc.) and then the body of the page would display different information depending on the selected tab (contact info, social media info, that kind of stuff). To ease the data load overhead I separated each tab into its own route in the app. This way each tab was actually a different route that would load its own data and since each tab had its own unique route, we could deep-link to the proper tab from anywhere in the link.
Continue reading “Angular 2 Warning: Router-Outlet in Templates”
One of the good things about Angular 1 was that it was easy to add the AngularJS library to your application and start using it without a lot of setup ceremony. Add a <script> tag to pull in angular.js, stick an ng-app attribute on the body or html tag, and you were ready to go. Of course, in a more complex application you would end up using additional libraries and probably setup a build process, but the barrier to getting started was low.
With Angular 2, getting started from scratch is not nearly as simple. While there are multiple “starter-packs” that have been created to help with generating a ready-to-go project, the thing that has most caught my attention is the Angular CLI (command-line-interface). Although the Angular CLI has not been officially released (it is in beta as of this writing), it already has a number of features that not only get you up and running quickly, they also help with adding other pieces of your application as it is developed.
Continue reading “Angular 2 CLI”
In Angular 1 I would frequently use the “resolve” property of routes in order to pre-load data for the route’s controller. This was accomplished with a Promise that would prevent the route from loading until the Promise was resolved. In Angular 2 this concept still exists, although now you can leverage Observables as well.
In my research I found plenty of examples on how to use Observables in your route’s resolve property, but almost no examples of Promises. Since I was more familiar and comfortable with Promises at the time, I wanted to use a Promise to fetch the necessary data for my route. I had to more or less piece together how to use a Promise to resolve a route, and then once that was done I was of course curious how it would differ had I opted to use an Observable instead.
Continue reading “Angular 2 Routing Resolve with Promises and Observables”
Angular 2 was finally released last week. I was able to spend some time getting familiar with the new Framework since RC4 and was working on several small projects to help with learning. As I continue to get a more in-depth understanding of Angular 2 I’ll be blogging on interesting things that are new and/or different from Angular 1. The first thing I’d like to go over is Angular 2 forms – specifically the use of ngModel.
There are three ways to use ngModel in Angular 2:
- With 2-way binding (similar to Angular 1)
- With 1-way binding
- With no direct binding to a model
Continue reading “Using ngModel in Angular2”