From Angular 1.5 to Angular 2 — What else can you do today?

If you have a team using Angular 1, you will inevitably and eventually need to migrate to Angular 2. What can you do today to mate the transition smooth? I am going to write some of the 2 actions we are taking today in a big banking application in order to facilitate the migration when the time comes.

Action 1: migrate to Angular 1.5

With angular 1.5 you can write components similar to what they will look like in Angular 2. First confusion is when can we use angular.component and what is the difference between component and directive?

Directive: use directives when you want add behaviour to an html element and/or perform low level manipulation on it. Also you have no UI. Eg.: validate-amount-field.directive.js, date-picker.directive.js.

Component give the idea a reusable piece of code or something directly related to the application domain. Eg.: user.component.js, account-list.component.js, alert.component.js

Angular2 is much smaller than angular 1. It means you have less to learn. No matter the framework you chose, you need to keep on learning.

In a nutshell, here are is a summary of what you need to learn, unlearn and relearn in order to be comfortable with Angular 2:

Unlearn from Angular 1

  • providers, services, factories, values: forget about them. In angular 2, services are plain ES6 with decorators.
  • Over 40 directives including such as ng-click, ng-focus, ng-whatever.
  • controllers: learn the angular 2 components. Again, plain ES6 class with decorators.

Re-learn for Angular 2

  • Directives: they are still directives and definition previously mentioned in this article still stands.
  • Forms: Angular 2 forms follow similar structure but are much more powerful (out of scope for article). Definitely work re-learn it.
  • Filters: they are now called Pipes. They are safe to run as they were designed: inside your template. In angular 1, filters run as many times your data is dirty. That causes slowness in your app and is known as a bad practice. You need to re-learn that Angular 2 fixes that and Pipes expect immutable data therefore run only once.
  • Router: Angular 1 we have the awesome ui-router. Angular 2 will need to re-learn router and child routes. At the moment I am writing this, Route docs says that Route has been deprecated. I still think that it is worth reading to known what is coming soon.

Learn new things in Angular 2

  • Typescript: Angular to heavily promotes Typescript. I am getting used to and I can say for sure that types are very useful to define parts of a big application. Also IDE support is incredible.
  • Decorators: They are annotations applied on ES6 classes. Eg.: @Component(…), @Pipe…)
  • Definitely learn and understand the new design for Components, @Input and and @Output.

Action 2: move away from Promises and use Observables

Promises have been ok for single resolution values. Despite of being not cancelable, people came up with pretty good hacks in order to stop the execution of the callback when you need to discard a given promise. One hacky way I have done was configure the $http config property timeout with promise rather than a integer. Then you reject the promise if you don’t want the promise resolve code to run.

This the most important step in my opinion: Modify your service layer to return an Observable rather than Promise.

If no had told you, Angular 2 has moved away from Promise. Angular 2 uses RxJs.Observables in the service layer. It means every time you make a service call, you get back an Observable.

Note: code snippets have not been compiled. They are here to illustrate or give a bit of live to my words.

Install rx-angular:

npm install rx-angular --save


import ‘rx-angular’;
const mod = angular.module(‘yourApp’, [‘rx’]);

In big apps, you don’t want all your angular 1 services having $http injected. You probably want to centralize all service calls in one place. If you don’t have, just create one like this:

import ‘rx-angular’;
const mod = angular.service(‘ApiManager’, ['$http', 'rx', function ($http, rx) {
  // manipulate config object here with data, url params etc...
  return {
sendRequest: function(config) {
return rx.Observable.fromPromise($http(config));

For big applications I would strongly recommend you to create an Observable manually and provide a ResponseModel to all controllers. This way you can intercept the response and configure with values that indicate errors or apply high level data transformation before you handle the ServiceResponse model to your controllers.

This is a simple ResponseModel that controllers will receive:

ServiceResponse {
data: object,
hasError: boolean,
errorDetails: object

In your services, make use of your ApiManager:

import ‘rx-angular’;
const mod = angular.service(‘MyService’, ['ApiManager', function (ApiManager) {
const myServiceConfig = {}; //Object with url, data, and other angular things.
return {
// it has to return a <ResponseModel>
getProductList: function() {
return ApiManager.sendRequest(myServiceConfig)
.filter(...) // rxjs filter and return a <ResponseModel>
.map() // rxjs map and return a <ResponseModel>
.doAction(); // example of rxjs operations

Note: Now your services do not know anything about HTTP. As your controllers can only receive a <ResponseModel>, you can easily loose all boiler plate code and make standard to only use a <ResponseModel> to retrieve data and inspect for errors.

I prefer to not use the Observable.onError because controllers will have to run clean up data or UI state upon success and/or error. Eg.: dismiss a spinner.

If this is your case, (I guess all web app will be) sanitize the response in a ResponseModel and give it in the success path of the Observable, even if there is a error. This is optional and arguable. However, my experience building big web apps using inconsistent REST API’s, showed me the best way is you decide what is success and error. You can fix those inconsistencies and hide the ugliness of API’s from your services and controllers.

The code that decides what is a success/error and creates the ResponseModel goes inside ApiManager service. You run this before you call onNext on the observable. Eg.:

var observable = rx.Observable.create(
function (observer) {
function successOrErrorInterceptor(response) {
     var res = responseInterceptFn(response);
observer.onNext(res); // This is a <ResponseModel>
return res;
$http(config).then(successOrErrorInterceptor, successOrErrorInterceptor).then(function () {
return observable;

If you chose to use the success path, you can surely run all clean up code inside the onCompleted, which is the third callback function of the Observable (details bellow inside controller code).

Again, you do not have to use the success path. You can stick with the onErrors if you desire.

Remember: Observables do not run onCompleted if something goes wrong. You have to manually run you cleanups in onNext and onError


Now modify all your controllers to subscribe to Observables. If you have a service called myService, replace myService.then with the code bellow:

// controller code
myService.subscribe( //
resp => {...}
error => {...},
=> {...} // onCompleted handler.

That’s all al have. Here are the 2 actions I recommend in order to progress to angular 2. One additional step would be add Typescript.

Summary the steps:

  • step 1: move to angular 1.5
  • step 1.5: add Typescript silently or not
  • step 2: change your service layer to use Observables

All articles in the web those days talk about steps 1 and “1.5". If you read this far, hope you can implement the most important step: the step 2.

I have not found one article that recommends move to Observables earler than Angular 2.


With Angular 2 there much less to learn. You can write better code and have access to the latest way of building web apps. Observables are pretty scary at the first glance. I recommend to get the word Observable out while you are using angular 1. Why? developers are pretty comfortable with Angular 1. They can surely learn RxJs as a intermediate step towards Angular 2. When they see angular 2, there will be much less to learn.

I noticed when we use a ResponseModel, it makes much easier to get the code consistent across multiple projects. This does not require Observables and I recommend in any project.

Thanks for reading, I hope you can take something out of this. Please share your experiences and preparation to migrate to angular 2.

Leonardo Correa

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.