bob.tsNOTE
This is an article I wrote for Leading EDJE in April of 2017. It is being moved off their site.
Article
Angular naming conventions ... we now have Angular, Angular JS, Angular 1, Angular 2, and Angular 4, and more to come. To say the least, conversations with coworkers and clients about angular in general has become more challenging. Then, when I had a chance to listen to the Angular Core team talking about Angular 4, they made it simple: "Angular" is Angular 2 and all versions moving forward while "AngularJS" is the reference to what we know today as Angular 1. This will be the convention I will be using within this article.
Google's Igor Minar said at the NG-BE 2016 Angular conference in Belgium that Google will jump from version 2 to version 4 so that the number of the upgrade correlates with the Angular version 4 router planned for usage with the release. Minar cautioned against getting too hung up on numbers and advised that the framework simply be called "Angular" anyway. "Let's not call it AngularJS, let's not call it Angular 2," he said, "because as we are releasing more and more of these versions, it's going to be super confusing for everybody."
When I had time to dig into Angular (2 at the time) on a real-world production project (in Ionic 2), I found the framework very easy to work with ... things just made sense. A great many things came together on this project; what I would have estimated at two to four months of development time was done and ready for real-world testing in under five weeks, while I was learning TypeScript, Angular, and Ionic 2 (mobile development)!
Some of the questions I get asked when presenting on Ionic 2 and Angular relate to whether these frameworks are production ready. In my opinion, Angular is production ready, and while there will be changes and improvements that should be kept up with, the framework is solid. The Google team is working at a fast pace, but they are generating framework code that is being used in production environments, this is the logical conclusion of a framework growing from a solid base. Ionic 2 is no longer in beta, but I would be hesitant to use it as production ready code, unless there is minimal use of device specific functionality. Both frameworks are great for generating Proof-of-Concept code.
Since working with Ionic 2, I have had a chance to listen to talks about React Native (still in the early stages of development) and am interested in learning more about this framework.
Now, on to what I learned from that initial project ...
Working in a framework that does not encourage two-way data binding was unusual at first, but a simple pattern to follow. I learned about Angular Modules, Components, then Templates and Metadata. Metadata is wrapped in a Decorator identifying the type of class being defined, the Metadata provides specific information about the class. When designing the Templates, I found that data binding brought a whole new level to what Angular was able to do.
Data Binding is a mechanism for coordinating parts of a template with parts of a Component.
| Binding | Example | Description |
|---|---|---|
| Interpolation | {{ value }} |
Displays a property value (from Component to DOM) |
| Property Binding | [property]="value" |
Passes the value (from Component to DOM) |
| Event Binding | (event)="function(value)" |
Calls a component method on an event (from DOM to Component) |
| Two-Way Binding | [(ng-model)]="property" |
This is an important form that combines property and event binding in a single notation, using the ngModel directive. |
In my opinion, while this methodology is more readable and easier to follow, the best part of data binding is elimination of the need for $scope.$apply or $timeout within my code to handle changing data.
If there was a challenging part, it was learning about Observables and how they can be used effectively. While Observables are not necessary in all cases, I started writing them on my project to get familiar with what they could do, how they would impact code and development.
Having worked extensively with Promises, I know that they handle a single event when an async operation completes or fails. There is more to it than that, but this gives us a starting point when discussing Observables. Both Promises and Observables provide us with abstractions that help deal with the asynchronous nature of our applications.
An Observable allows us to pass zero or more events where the callback is called for each event. Often Observable is preferred over Promise because it provides many of the features of Promise, and more. It does not matter if you want to handle zero, one, or multiple events. You can utilize the same API in both cases.
Observables can also be cancelled, which is an advantage over Promises in most cases. If the result of an HTTP request to a server or some other expensive async operation is not needed anymore, the subscription to an Observable allows the developer to cancel the subscription, while a Promise will eventually call the success or fail callback even when you do not need the notification or the result it provides.
Observables also provide operators like map, forEach, reduce, ... similar to an array.
Suppose that you are building a search function that should instantly show you results as you type. This sounds familiar, but there are a lot of challenges that come with this task. I have seen a lot of creative code over the years to handle the issues that have to be handled here.
- We do not want to hit the server endpoint every time user presses a key. Basically, we only want to hit it once the user has stopped typing instead of with every keystroke.
- We also do not want to hit the search endpoint with the same query params for subsequent requests.
- We also need to deal with out-of-order responses. When we have multiple requests in-flight at the same time we must account for cases where they come back in unexpected order. Imagine we first type computer, stop, a request goes out, we type car, stop, a request goes out. Now we have two requests in-flight. Unfortunately, the request that carries the results for computer comes back after the request that carries the results for car.
Observables make handling these cases easy. In fact, this is one of the primary examples for using Observables at this time.
What I have learned:
- The naming conventions used by Google will take some time to sink in.
- Angular is a truly robust framework, production ready.
- The learning curve when using Angular is minimal since most of the framework is intuitive.
- Many of the hassles of Angular JS are reworked in a rich way.
- Ionic 2, based on Angular, while fun, is not robust enough at this time for production.
- React Native may be an intriguing solution for mobile development.
- Data-binding and Observables have come a long way and can take away much developer pain.
References:
