When working with Angular Routing, it’s very useful to be able to respond to routing events – the most obvious and useful being when the route changes. In AngularJS this was accomplished with by attaching a callback function to one the “$routeChange” events on the $scope. In Angular the concept is similar but has some key (and in my opinion, useful) differences.
Once you have a reference to the Router for your application you can subscribe to its “events” observable. This observable will emit a route-event whenever applicable that you can listen for. Being an observable you can subscribe to it in multiple places, filter for the specific event you want, transform the raw event, or anything else you could do with an observable.
Continue reading “Router Events in Angular”
Many years ago we worked on a project that would allow the client to perform inspections digitally on the various restaurants in their franchise. One of the goals of these inspections was to make sure the restaurants were following the client’s procedures and policies. These procedures and policies are constantly being reviewed and updated, so one of the main requirements of this inspection project was to allow the client to update the inspection on the fly without requiring development updates each time. In other words, it needed to be reasonably configurable by the client. We ultimately created a dynamic form that would be constructed in real-time based on data provided by the client. The idea was that as the client updated their procedures and policies, they would add/remove items from the form to keep it up-to-date.
Continue reading “Data Storage: SharePoint v. SQL”
I had an issue recently with a pretty standard form in Angular 2. The form had some required fields, one of which was a drop down / select field that wouldn’t populate with options until the user had made some selections earlier in the form. The submit button for the form was disabled until all required fields were filled in.
The issue arose when the client started testing the form in their environment. Despite completely filling out the form, the submit button would stay disabled. Obviously something was wrong.
Continue reading “Dynamically Populating Drop Downs in Different Browsers”
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”
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”
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”