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.
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.
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.
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.
I was in requirements gathering meetings all day, so this evening I was doing some “actual work” when a I received an email congratulating me on my Microsoft certification. Being that I haven’t taken an exam in a few months I was a little perplexed. Not that I mind getting more certifications but I generally like to actually know about it beforehand.
Some great news for the guys and gals managing small scale SharePoint 2016 Farms – MinRole installation just got a lot more feasible.
When MinRole was originally announced, I looked at it as a great justification to make the move to SharePoint 2016. Imagine, no longer needing to take down production SharePoint environments in order to apply patches… Sign me up!
Unfortunately, when the requirements came out for the MinRole setup, many organizations could not justify setting up 8 servers to create a High Availability SharePoint Farm.
Microsoft responded to customer feedback today at Ignite in a big way with the announcement that Feature Pack 1 for SharePoint 2016 (available in November) will include an option for creating a High Availability SharePoint 2016 Farm with just 4 servers. By combining the Web Front End and Distributed Cache roles as well as the Application and Search roles Microsoft is really opening the door for small/mid organizations to treat their SharePoint 2016 environments as “first class citizens”.
I am truly excited by this announcement. As a consultant I often times find myself struggling to keep the customer happy with the overall cost of a system while still following best practices. This enhancement not only makes small to mid-size SharePoint 2016 Farm Administrators lives easier, it makes mine a bit easier too.
For a full listing of details on Feature Pack 1 please reference the Office blog Announcing Feature Pack 1 for SharePoint Server 2016—cloud-born and future-proof
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
Angular 2 is the hot new thing, but like any other new technology out there, documentation and examples are really sparse and there’s a lot of head scratching trying to figure out why things that seem like they should work…aren’t.
I spent some time recently working with TemplateRefs in Angular 2, trying to access templates defined via a <template> tag in my HTML from the component code.
Angular 2 officially released last week – 9/14/16 – which was excellent timing for me as I had just been put on a new project that would be utilizing Angular 2 (at the client’s request). After spending a few days familiarizing myself with Angular 2 I dived right into the project.
As an aside, and to jump on the bandwagon… why is this called Angular 2?! I had to forget more or less everything I learned in Angular 1 when transitioning to Angular 2. It might as well have been called Componentular or something for how much Angular 2 has in common with Angular 1.