When Will It Be Ready?

Angular 2 is not ready for production use today. The current available version is “alpha” and is still undergoing changes. What’s more important, the documentation is very limited. We would not advise anyone to use Angular 2 in production at this point. When will Angular 2 be ready? The honest answer is that nobody knows. At Rangle.io, however, we are currently proceeding with an assumption that highly adventurous people may want to start seriously looking at it in the fall, with the rest of the community catching up in the coming winter and spring.

So, What Should We Do Meanwhile?

This situation puts a lot of projects in a seemingly awkward situation - especially for those who are starting to work on new apps right now. You can’t yet go with Angular 2. Yet it feels unfortunate to be working with Angular 1.x knowing that this version of the framework will be obsolete within a year.

But it’s not all bad. The thing is, the level of effort to transition your app from Angular 1 to Angular 2 will likely fall somewhere between “You might as well rewrite it from scratch” to “No big deal, really”, and it will all depend on how your Angular 1 app is written. If you’ve been a friend of $scope and $watch, plan for heavy heavy refactoring. If you’ve been following the best practices of the sort that we’ve been preaching in our talks and training sessions, your effort will be a lot less.

But you don’t have to stop there. Now that we have a fairly clear picture of what Angular 2 is going to look like, we can start writing our Angular 1.x apps in a manner that would really minimize the cost of transition later. This is a topic we started looking a few months ago. We’ll be discussing some of our conclusions in an upcoming webinar. I outline below some of the key ideas. We’ll also be discussing some of the issues in separate blog posts over the next few weeks.

TypeScript

You can use Angular 2 without TypeScript, but you probably don’t want to do this. So, one of the first steps in preparing for Angular 2 is to introduce TypeScript into your workflow and start writing your controllers and services as TypeScript classes. You would also want to start using ES6 classes and loading them using SystemJS. For projects that haven’t been using a transpiler before, this may present somewhat of a change in how your tooling is setup. We’ll try to address this an upcoming blog post.

The good news, though, is that controllers and services implemented as TypeScript classes work with Angular 1. By the way, TypeScript and ES6 offer tons of great features, but you don’t need to start learning all of them. What you want to focus on at this point is classes, arrow functions, and modules.

Decorators

One of the neat features of TypeScript that Angular 2 uses is decorators. Those are the @Component thingies that you see in Angular 2 examples. Decorators are a proposed feature for ES2016, and are also supported by TypeScript. There are libraries out there that implement Angular 2 decorators using Angular 1. After looking at those, we decided to pass on them. Decorator libraries go a long way in making your Angular 1 code look like Angular 2, but for the most part the resemblance they bring is rather superficial. We did end up implementing our own @Inject decorator, which we use to annotate injectable arguments to controller and service constructors. Instead of @Component, however, we decided to go with a less magical makeComponent() function that takes a component controller and some options and produces a directive.

Components and Flux

Instead of spending more time worrying about how our code looks, we decided to focus on making sure that our transitional apps are using an architecture that is fully aligned with Angular 2. This means, most obviously, no $scope, anywhere. Less obviously, though, it means fully componentizing our apps and thinking a lot more about how components communicate with each other. In addition to looking at what Angular 2 offers, we also considered closely how components are handled in ReactJS and Flux. We settled on an approach that we believe would both work well with Angular 2 as well as aligning with several ReactJS best practices. (We use Angular on some of our projects and React on others, so settling on a shared architecture would help our developers move between Angular and React projects seamlessly.) We are working on a blog post that would address the approach we decided on.