Introduction to ES6 and Angular 2 – RightBrain Networks

Some time ago, after Adobe Flash had fallen to the forces of the open source army, many veterans of Flash such as myself found a home in JavaScript. From the perspective of a designer/Flash-type person, I am here to tell you why Angular 2 makes life easier in the world of web applications and why it feels very familiar. Bear with me, as this blog post will serve as an introduction to ES6 and Angular 2. (ES6 is the latest release of JavaScript as of this blog post.) I encourage you to explore further, and I will provide some paths you can embark on throughout.

So first ES6…

Importing and Exporting Scripts, Being Modular

Do you remember importing things in Flash? Like modules or components? ES6 uses modules as well, allowing you to break up your scripts and empowering you to build scalable applications. It doesn’t rely on external libraries or an AMD loader like requirejs. The compiler does all of that for you. (I suggest starting with Brunch and Babel.)

When you write code, you only need to ask the compiler to import your components. You state all of these components at the top of the code so that they are imported before you attempt to use them. (JavaScript runs our main loop from top to bottom.)

ES6 Brings More Syntax

In vanilla JavaScript, ‘Classes’ can only be simulated by declaring them as a runtime function. That works just fine, but it lacks the syntax that keeps our codebase legible and easy to approach.

Notice how the anonymous function below is now replaced with a distinctive class. Not going too far into what classes also bring to the table, just know that I found it refreshing to have more syntax in my a large JavaScript applications.

JavaScript

ES6

ES6 Variable Access

Remember public and private in ActionScript? Classes in ES6 can have public and private items.

For the most part, this is ES6 and less Angular-related. However, pieces of Angular 2 like @Input and @Output must be declared as ‘public’. Aside from a few instances, you will most often work within the class scope to construct a component. So private should be your most common type.

These distinctions become important to Angular in certain contexts. One of which is when you declare parameters in the constructor. You’ll need to declare Angular-specific things like services in your constructor as one of these two types. Private is preferred unless you’re doing something special that I haven’t encountered as of yet.

Below is an example of a constructor and the parameters I’m speaking of. ‘myOctagonService’ is declared as private. Declaring a type allows us to later reference these properties through the ’this’ object.

Object Oriented is Team Oriented

Angular 2 doesn’t shine simply because it’s in ES6, giving you classes, for example. It shines because it fixes a lot of problems that plagued AngularJS and made it harder for teams to work on large-scale projects.

Repository Merging was one such pain point for us here at RightBrain Networks. Because AngularJS was rather ambiguous and very open in how you could develop with it, when coupled with the large amounts of boilerplate in the code it became messy. And if you were working on a file in tandem, it got even worse. Angular 2 mitigates this and reduces the amount of actual code you need to write. It also has a much more thought out ‘order’ to it. You can’t abuse (most often my mistake) much of it. It’s much more refined and overall this has helped to eliminate most merge conflicts while ensuring a unified codebase style.

If you are a Flash developer like myself, this idea of asynchronous code being wrapped in an Object Oriented world is nothing new. This Object Oriented looking wrapper could possibly be viewed as an unnecessary abstraction layer. However, on a large team having a bit of verbosity is very helpful. Context can disappear without implicit instruction/context, which is often in short supply. So the additional syntax makes headaches less likely among users of various experience levels. Context and consistency are always your ally.

It’s Still JavaScript, But Don’t Fret

This is powerful stuff. But it can’t all be good, can it?

Nope, it’s dependency land, filled with open source, so it will inevitably pass you onto some kind of open source nonsense of breaking versions and that jazz. However NPM, GIT and Angular CLI will solve most of those problems.

With patience you will seamlessly compile and also ‘host’ your build virtually on your local machine so you can develop your Angular frontend in real time.

So no more MAMP.

No more refresh button.

No more Filezilla.

No more GUIs.

Open Source is Good Source

The open source community has many ready to go ‘boilerplates’ that require little shell/terminal experience to run. They all use NPM and GIT, and some use the CLI. So the terminal is where it’s at. Don’t be afraid of it. It is your friend. It’s now my friend, and I was never using the terminal before a few years ago.

Here is how you can set up your NPM, for example:

You are then prompted to enter a few things such as project title, version, etc. You have the option to skip most of this metadata declaration and set your NPM configuration to a default of some kind.

Once you’ve finished the initial set up this operation creates a ‘package.json’ in your directory, which contains all the stuff you filled out. This document will act as an index for all your dependencies and build script cues.

Next you need to install Angular 2, so submit:

Once you’ve done this, including that –save flag, you’ll see that your ‘package.json’ has changed. Angular is chilling in the dependencies object. This is where you can manage all of the dependencies that Node and JavaScript have made so prominent lately.

Compiling with Terminal

When it comes to actually compiling Angular, you can either follow Angular’s guide using SystemJS, or you can try Brunch, Webpack, or even Grunt or Gulp.

Grunt and Gulp are great if you want micro-control over your build pipeline, while Brunch is great for getting it going NOW. Webpack is great when you want to create a massive scaling application. It can be tough at first to use, but it eventually becomes a powerful tool in your stack.

Once you clear these hurdles you can start developing. And so now onto Angular 2.

Using ‘This’ instead of ‘Scope’

Scope Soup was one of the things I just irked at every time I wrote AngularJS. I tried to emulate stateful objects to track changes, binding the changes to the scope, and I would end up with scope prefixing almost everything. Instead of just using JavaScript’s inheritance, AngularJS tried to isolate your namespaces, which is great in theory, but more namespaces easily translated to more confusion on large teams. But in Angular 2 the scope object is kind of baked into the native ‘this’ object. As a result, it’s easier to pass the scope or ‘this’ around your component/class. ES6 complements this approach in part because of arrow functions, allowing ‘this’ to descend into the guts of its methods. With arrow functions you could, in theory, never need to ‘point’ to this if you are inside of it.

So no more declaring a pointer to ‘this’, like below:

Instead you can just write:

A New Way to Scope

Further good news is that the relationship between bindings once stated in a ‘scope block’ and events in the template are now illustrated by a standardized iconography. Borrowing from Handlebars, Ember, etc., the relationship is now determined by wrapping the name of the bound variable in one of the following:

One-way binding:

Event Binding:

Two-way Binding:

Further, creating an isolated scope that accepts properties from the template is now done in the code by decorators such as @Input or @Output. It feels more natural this way. Instead of binding properties using an object literal (dictionary) that is later passed into your constructor, you’re binding these properties in the class declaration space itself.

Parent: Component Template:

Component:

Component Template:

How and when you use these bindings within the new architecture is determined by the context of your application. (Read more about templates.)

Your application’s data-relationships can be furthered empowered by Observables coupled with Redux, creating a reactive component. (See the Gist.)

Declaring a Component, Simplified

A bare-bones component with a service can look like this in Angular 2:

The @Component decorator is new. This is a very simple declaration that tells the compiler that the ES6 documents exported class is an Angular 2 component. While very simple, @Component is also very extensible. The selector dictates how the component will behave and be set up inside Angular’s main loop. There are many other ways to initialize your component using the decorator’s metadata properties.

After Compiling, You Get JavaScript

This is what the above looks like when the compiler exports it:

You can ignore the decorator aspect, but the rest is very much why ES6 makes our code look and feel more legible–more like ActionScript3 or more like Object Oriented Languages. It makes more sense, and it’s easier to follow.

Once compiled, ES6 and Angular give you client-side JavaScript. You can do anything in JavaScript that you can do in ES6, but it’s a whole heck of a lot messier, so it’s a contextual choice to use the stack I presented to you.

Head West Young Developer

I covered a lot in this introduction to ES6 and Angular 2, and it certainly looks like the Wild West out here in web app land. I hope I’ve at least piqued your interest and not scared you off. If, like me, you are a Flash veteran, I hope you find a friend in ES6 and Angular.

From here don’t be afraid to use other technologies like React, which also benefits from many of the wonderful things I mentioned here. Angular 2 is a great new out-of-the-box system that gives you control and fast results. It should be around for a while–hopefully longer than ActionScript, but there are so many frameworks out there that Angular 2 cannot usurp all of them. Change will keep knocking on the door, and you will always need to answer it.

Save