Learn Angular: The Collection

Chapter 1: Angular Introduction: What It Is, and Why You Should Use It

by Ilya Bodrov-Krukowski

In this article, I’m going to give you a general overview of a very popular and widely used client-side framework called Angular. This Angular introduction is mostly aimed at newcomer developers who have little experience with JS frameworks and wish to learn the basic idea behind Angular as well as understand its differences from AngularJS.

A JavaScript framework is a kind of buzzword these days: everyone keeps discussing these frameworks, and many developers are arguing about the best solution.

So, let’s get this Angular introduction started, shall we?

Why Do I Need a Framework?

If you’re not sure what a JavaScript (or client-side) framework is, that’s a technology providing us the right tools to build a web application while also defining how it should be designed and how the code should be organized.

Most JS frameworks these days are opinionated, meaning they have their own philosophy of how the web app should be built and you may need to spend some time to learn the core concepts. Other solutions, like Backbone, do not instruct developers on how they should craft the project, thus some people even call such technologies simply libraries, rather than frameworks.

Actually, JavaScript frameworks emerged not that long ago. I remember times where websites were built with poorly structured JS code (in many cases, powered by jQuery). However, client-side UIs have become more and more complex, and JavaScript lost its reputation as a toy language. Modern websites rely heavily on JS and the need to properly organize (and test!) the code has arisen. Therefore, client-side frameworks have become popular and nowadays there are at least dozen of them.

Angular Introduction: What Angular IS

AngularJS used to be the golden child among JavaScript frameworks, as it was initially introduced by Google corporation in 2012. It was built with the Model-View-Controller concept in mind, though authors of the framework often called it Model-View-* or even Model-View-Whatever.

The framework, written in pure JavaScript, was intended to decouple an application’s logic from DOM manipulation, and aimed at dynamic page updates. Still, it wasn’t very intrusive: you could have only a part of the page controlled by AngularJS. This framework introduced many powerful features allowing the developer to create rich, single-page applications quite easily.

Specifically, an interesting concept of data binding was introduced that meant automatic updates of the view whenever the model (data) changed, and vice versa. On top of that, the idea of directives was presented, which allowed inventing your own HTML tags, brought to life by JavaScript. For example, you may write:

This is a custom tag that will be processed by AngularJS and turned to a full-fledged calendar as instructed by the underlying code. (Of course, your job would be to code the appropriate directive.)

Another quite important thing was Dependency Injection, which allowed application components to be wired together in a way that facilitated reusable and testable code. Of course, there’s much more to AngularJS, but we’re not going to discuss it thoroughly in this article.

AngularJS became popular very quickly and received a lot of traction. Still, its maintainers decided to take another step further and proceeded to develop a new version which was initially named Angular (later, simply Angular without the JS part). It’s no coincidence the framework received a new name: actually, it was fully re-written and redesigned, while many concepts were reconsidered.

The first stable release of Angular was published in 2016, and since then AngularJS started to lose its popularity in favor of a new version. One of the main features of Angular was the ability to develop for multiple platforms: web, mobile, and native desktop (whereas AngularJS has no mobile support out of the box).

Then, to make things even more complex, by the end of 2016, Angular 4 was released. So, where is version 3?, you might wonder. I was asking the same question, as it appears that version 3 was never published at all! How could this happen? As explained in the official blog post, maintainers decided to stick with the semantic versioning since Angular.

Following this principle, changing the major version (for example, 2.x.x becomes 3.x.x) means that some breaking changes were introduced. The problem is that the Angular Router component was already on version 3. Therefore, to fix this misalignment it was decided to skip Angular 3 altogether. Luckily, the transition from Angular to 4 was less painful than from AngularJS to Angular, though many developers were still quite confused about all this mess.

Angular 5 was released in November 2017. It is also backwards compatible with prior Angular versions. Angular 6 should be released quite soon, hopefully giving us even more cool features and enhancements.

Angular Introduction: the Advantages of Angular

So, why Angular? Well, because it’s supported on various platforms (web, mobile, desktop native), it’s powerful, modern, has a nice ecosystem, and it’s just cool. Not convinced? Let me be a bit more eloquent then:

Angular presents you not only the tools but also design patterns to build your project in a maintainable way. When an Angular application is crafted properly, you don’t end up with a tangle of classes and methods that are hard to modify and even harder to test. The code is structured conveniently and you won’t need to spend much time in order to understand what is going on.

It’s JavaScript, but better. Angular is built with TypeScript, which in turn relies on JS ES6. You don’t need to learn a totally new language, but you still receive features like static typing, interfaces, classes, namespaces, decorators etc.

No need to reinvent the bicycle. With Angular, you already have lots of tools to start crafting the application right away. You have directives to give HTML elements dynamic behavior. You can power up the forms using FormControl and introduce various validation rules. You may easily send asynchronous HTTP requests of various types. You can set up routing with little hassle. And there are many more goodies that Angular can offer us!

Components are decoupled. Angular strived to remove tight coupling between various components of the application. Injection happens in NodeJS-style and you may replace various components with ease.

All DOM manipulation happens where it should happen. With Angular, you don’t tightly couple presentation and the application’s logic making your markup much cleaner and simpler.

Testing is at the heart. Angular is meant to be thoroughly tested and it supports both unit and end-to-end testing with tools like Jasmine and Protractor.

Angular is mobile and desktop-ready, meaning you have one framework for multiple platforms.

Angular is actively maintained and has a large community and ecosystem. You can find lots of materials on this framework as well as many useful third-party tools.

So, we can say that Angular is not just a framework, but rather a platform that empowers developers to build applications for the web, mobile, and the desktop. You may learn more about its architecture in this guide.

Angular Introduction: Angular’s Complexities

I have to say that, unfortunately, Angular is quite a big and complex framework with its own philosophy, which can be challenging for newcomers to understand and get used to. Learning the framework’s concepts is not the only task, however; on top of this, you also have to be comfortable with a handful of additional technologies:

It’s recommended to code Angular apps in TypeScript, so you must understand it. It is possible to write the code with modern JavaScript (ES6), though I rarely see people doing this.

TypeScript is a superset of JavaScript, so you’ll need to be comfortable with it as well.

It’s a good idea to get the grasp of the Angular CLI to speed up the development process even further.

Node’s package manager npm is used extensively to install Angular itself and other components, so you’ll need to be comfortable with that as well.

Learning how to set up a task runner like Gulp or Grunt can come in really handy, as there can be lots of things to be done before the application is actually deployed to production.

Using minifiers (like UglifyJS) and bundlers (like Webpack) is also very common these days.

While developing the app, it’s vital to be able to debug the code, so you should know how to work with debugging tools like Augury.

Of course, it’s very important to test Angular applications, which can become very complex. One of the most popular testing tools out there are called Jasmine (which is a framework for testing) and Protractor (which is used for end-to-end testing).

So, as you see, there are quite a lot of things to learn in order to start creating client-side web applications. But don’t be put off: there are numerous resources on the net that may help you learn all these tools and technologies. Of course, you’ll need some time to get the grasp of them, but as a result, you’ll get valuable experience and will be able to create complex apps with confidence.

One last thing worth mentioning is that sometimes using Angular for an app may be overkill. If you have a small or medium-sized project without any complex user interfaces and interactions, it may be a much better idea to stick with plain old JavaScript. Therefore, it’s very important to assess all the requirements, features of the new application, as well as take deadlines into consideration before making a decision on whether to use a JavaScript framework or not.

Conclusion

In this Angular introduction, we’ve discussed Angular, a client-side framework supporting multiple platforms. We’ve covered some of its features and concepts, and also have seen how it differs from AngularJS, the previous version of the framework.

Hopefully you’ve now got a basic idea of what Angular is and in what cases it may come in handy!

Chapter 2: AngularJS and Angular: a Detailed Comparison

by Manjunath M

This article compares the major differences between the the original AngularJS and Angular. If you’re currently stuck with an AngularJS project and not sure whether you should make the jump, this article should help you get started.

In recent years, we’ve seen Angular grow tremendously as a framework and as a platform for developing single page applications (SPAs) and progressive web apps (PWAs). AngularJS was built on top of the idea that declarative programming should be used for building the views. This required decoupling the DOM manipulation from the business logic of the application and the approach had many benefits on its own.

However, AngularJS had many shortcomings in terms of performance and how things worked under the hood. Hence, the development team spent a year rewriting the code from scratch and finally released Angular 2 in late 2016. Most developers felt that Angular was a different platform that had very little resemblance to the original AngularJS.

So let’s compare and contrast AngularJS and Angular.

Frameworks in AngularJS and Angular

AngularJS follows the traditional MVC architecture that comprises a model, a view and a controller.

Controller: the controller represents how user interactions are handled and binds both the model and the view.

Views: the view represents the presentation layer and the actual UI.

Model: the model is an abstract representation of your data.

Some developers are of the opinion that AngularJS follows MVVM pattern that replaces the Controller with a View-Model. A View-Model is a JavaScript function that’s similar to that of the controller. What makes it special is that it synchronizes the data between a view and a model. The changes made to a UI element automatically propagate to the model and vice versa.

The following diagram shows how various AngularJS pieces are connected together.

You can read more about AngularJS’s architecture on the official documentation page.

Angular, on the other, hand has a component-based architecture. Every Angular application has at least one component known as the root component. Each component has an associated class that’s responsible for handling the business logic and a template that represents the view layer. Multiple, closely related components can be stacked together to create a module and each module forms a functional unit on its own.

As you can see in the figure, the component is bound to the template. Components are composed using TypeScript classes and templates are attached to them using @Component annotations. Services can be injected into a component using Angular’s dependency injection subsystem. The concept of modules in Angular is drastically different from that of the AngularJS modules. An NgModule is a container for defining a functional unit. An NgModule can comprise components, services and other functions. The modular unit can then be imported and used with other modules.

All the Angular concepts are better explained at Angular.io.

Templates in AngularJS and Angular

In AngularJS the template is written using HTML. To make it dynamic, you can add AngularJS-specific code such as attributes, markups, filters and form controls. In addition, it supports the two-way data binding technique mentioned earlier. The following code snippet demonstrates the use of directives and double curly brackets within the template:

  MyController>

    foo value=bar>

    button ng-click=changeFoo()>{{buttonText}}

In Angular, AngularJS’s template structure was reworked and lots of new features were added to the templates. The primary difference was that each component had a template attached to it. All the HTML elements except , , , and

Dependency Injection in AngularJS and Angular

Dependency Injection is a design pattern that takes care of satisfying dependencies and injecting them into the components when they’re required. This avoids the need for hardcoding the dependencies into a component. AngularJS has an injector subsystem that’s responsible for creating components, injecting dependencies and resolving the list all dependencies. The following components can be injected on an on-demand basis:

value

factory

service

provider

constant

Services, directives and filters can be injected by using a factory method. Here’s an example of a factory method in action. The factory method is registered with a module named myModule:

angular.module('myModule', [])

.factory('serviceId', ['depService', function(depService) {

  // ...

}])

.directive('directiveName', ['depService', function(depService) {

  // ...

}])

.filter('filterName', ['depService', function(depService) {

  // ...

}]);

Although the approach has stayed the same, Angular has a newer dependency injection system that’s different from that of the older DI pattern. Angular’s dependency injection is managed through the @NgModule array that comprises providers and declarations. The declarations array is the space where components and directives are declared. Dependencies and services are registered through the providers array.

Imagine you have a service that retrieves a list of contacts called ContactlistService and provides it to a ContactList component. You’d first need to register the ContactlistService in app.module.ts inside the providers array. Next, you’d need to inject the service into the component as follows:

import { Component }  from '@angular/core';

import { Contact }        from './contact';

import { ContactListService } from './contactlist.service';

@Component({

  selector: 'app-contacts-list',

  template: `

      {{contact.id}} - {{contact.name}} - {{contact.number}}

  `

})

export class ContactListComponent {

  contacts: Contact[];

  constructor(contactlistService: ContactlistService) {

    this.contacts = contactlistService.getcontacts();

  }

}

Here, we’re telling Angular to inject the service into the component’s constructor.

JavaScript vs TypeScript

AngularJS is a pure JavaScript framework, and models in AngularJS are plain old JavaScript objects. This makes the whole process of setting up the project a lot easier. Any developer with some basic JavaScript experience can get started with the framework. Because of this, AngularJS.0 has a very gentle learning curve compared to that of other front-end frameworks.

Angular introduced TypeScript as the default language for building applications. TypeScript is a syntactic superset of JavaScript that compiles down to plain JavaScript. The Angular team chose TypeScript over JavaScript because of the type annotation feature that lets you do optional static type checking. Type checking can prevent compile-time errors crawling into your code that would otherwise go unnoticed. This makes your JavaScript code more predictable.

Apart from that, TypeScript is also popular for its classes, interfaces and decorators (class decorators, property decorators and parameter decorators). TypeScript classes are used by Angular for defining components. @Component is a popular example of how class decorators are used to attach metadata to a component. Usually, this includes component configuration details such as the template selector tag, the templateUrl and a providers array so that you can inject any related dependency into that component:

@Component({

  selector:    'app-hero-list',

  templateUrl: './hero-list.component.html',

  providers:  [ HeroService ]

})

export class HeroListComponent implements OnInit {

/* . . . */

}

Tooling Support for AngularJS and Angular

Better tooling support helps developers build things faster and it adds to the overall development workflow. A command-line interface (CLI) for instance can considerably reduce the amount of time spent creating an application from scratch. Similarly, there are other tools such as IDEs, text editors, test toolkits etc. that help you make development a whole lot easier.

AngularJS didn’t have an official CLI, but there were many third-party generators and tools available. For the IDE, WebStorm and Aptana were the popular choices among the developers. If you’re like me, you could customize a normal text editor like the Submlime Text editor and add the right plugins into it. AngularJS has a browser extension for debugging and testing called ng-inspector. The structure of AngularJS allowed third-party modules to be imported without any hassle. You can find all the popular ng modules at ngmodules.org, which is an open-source project for hosting AngularJS modules.

Angular has more tooling support compared to AngularJS. There’s an official CLI that lets you initialize new projects, serve them and also build optimized bundles for production. You can read more about Angular CLI at GitHub. Because Angular uses TypeScript instead of JavaScript, Visual Studio is supported as an IDE. That’s not all. There are many IDE plugins and independent tools that help you automate and speed up certain aspects of your development cycle. Augury for debugging, NgRev for code analysis, Codelyzer for code validation etc. are pretty useful tools.

Summary

AngularJS had many flaws — most of them related to performance — but it used to be the first go-to choice for rapid prototyping. However, it doesn’t make any sense to go back to AngularJS or maintain an AngularJS project anymore. If you haven’t already made the shift, you should consider doing so.

In this article, we’ve covered the top five differences between AngularJS and Angular. Except for the template structure and the approach for dependency injection, almost all other features were revamped. Many of the popular AngularJS.0 features such as controllers, scope, directives, module definition etc. have been replaced with other alternatives. Furthermore, the underlying language has been changed and the structure modified.

Chapter 3: An Introduction to TypeScript: Static Typing for the Web

by Byron Houwens

TypeScript is one of many attempts at creating a better experience with JavaScript.

Oh, I’m using Gulp because of reason A or Oh, I’m using Redux because of reason B. You hear these sorts of things from front-end developers all the time. It’s become fashionable to use new ways of improving on JavaScript’s old faults, and that’s not a bad thing. Even ES2015 and the updates that have followed have been pretty determined attempts at righting those wrongs.

TypeScript is a promising change to our favorite language that may be having a significant impact on JavaScript’s future.

What Exactly is TypeScript?

TypeScript is a strongly-typed superset of JavaScript, which means it adds some syntactical benefits to the language while still letting you write normal JavaScript if you want to. It encourages a more declarative style of programming through things like interfaces and static typing (more on these later), offers modules and classes, and most importantly, integrates relatively well with popular JavaScript libraries and code. You could think of it as a strongly static layer over current JavaScript that has a few features to make life (and debugging especially) a bit more bearable.

TypeScript gained particular attention a few years ago because it was selected for full support by Angular and following (which is also written in TypeScript itself). It’s also developed by Microsoft, which means it has the backing of two major tech companies (not a bad place for any language). Since this time, it’s gained more of a following and mainstream status.

Needless to say, TypeScript is definitely worth looking into.

How Does it Work?

TypeScript actually looks much like modern JavaScript. At the most basic level, it introduces a static typing paradigm to JavaScript, so instead of the following:

var name = Susan,

    age = 25,

    hasCode = true;

We could write the following:

let name: string = Susan,

    age: number = 25,

    hasCode: boolean = true;

As you can see, there’s not a whole lot of difference here. All we’re doing is explicitly telling the system what type each variable is; we’re telling it from the get-go that name is a string and age is a number. But that just seems like we have to write more code. Why bother telling the system such specific information? Because it gives the system more information about our program, which in turn means it can catch errors that we might make further down the road.

Imagine, for instance, you have something like this in your code:

var age = 25;

age = twenty-five;

Mutating a variable like this and changing its type will likely end up breaking stuff somewhere else, especially in a really big program, so it’s great if the compiler can catch this before we load this up in our browser and have to sit for half an hour looking for the issue ourselves. Basically, it makes our program safer and more secure from bugs.

There’s more, though. Here’s an example from the TypeScript website intro tutorial (which you can find here):

interface Person {

    firstname: string;

    lastname: string;

}

function greeter(person : Person):string {

    return Hello, + person.firstname + + person.lastname;

}

let user = {firstname: Jane, lastname: User};

document.body.innerHTML = greeter(user);

Now there are a few more unusual things here than we had before. We’ve got a run-of-the-mill object, called user, containing a first and last name, and that’s being passed to greeter() and the output inserted into the body of the document. But there is some bizarre-looking stuff in the arguments of thegreeter function, as well as something called an interface.

Let’s start with the greeter function:

function greeter(person: Person):string {

    return Hello, + person.firstname + + person.lastname;

}

We can see that greeter takes a person parameter and we expect it to be of type Person. In this way, we can be sure that when we ask for that person’s first name, it will definitely be there and we won’t induce headaches upon ourselves if it fails. The :string after the function parameters tells us what type we expect this function to return when we call it.

The body of the function is nothing complicated but, of course, by now you’re probably wondering what on earth a Person type actually is. This is where the interface feature comes in:

interface Person {

    firstname: string;

    lastname: string;

}

Interfaces are used in TypeScript to define the structure of objects (and only objects). In this example, we’re saying that any variable of type Person must be an object containing a firstname and a lastname property, both of the string type. We’re basically creating a custom type for our object.

This is useful because it tells the compiler, as well as yourself and any developer who will work on this in the future, exactly what type of data to expect. We’re basically modelling the object properties, creating something we can reference if we need to debug later. This is often why you’ll see interfaces at the top of TypeScript files, as they give us a good idea of the data the program is working with in the rest of the file.

In our example, if we use this Person interface with a variable at any point in the program and it doesn’t contain either a firstname or lastname, both of type string (our user object thankfully does), then the compiler will moan at us and we will be forced to mend our ways.

Not only that, but having static typing means that an IDE or editor with support for TypeScript will be able to provide us with very good, very specific hinting and auto-completion so that we can develop code that is both faster and safer.

There are many more features that TypeScript allows us to use, such as generics and namespaces, so at least a quick read of their documentation is highly recommended.

How Do I Set it Up?

Because TypeScript is a superset of JavaScript, we’ll need to transpile it into JavaScript if we want to use it in the browser. Thankfully, it integrates well with a number of task runners and bundlers already.

If you’re just looking to play around with it locally first in particular, you can install TypeScript globally via npm and use it from the command line with the tsc command, like so:

tsc your-typescript-file.ts

This will output a JavaScript file, in this case called your-typescript-file.js, which you can then use in the browser as per usual. Setting it up in a project, though, will almost certainly entail setting up a proper tsconfig.json.

This file denotes that the project is a TypeScript project, and allows us to set a number of configuration options. Here’s a truncated example from the docs:

{

    compilerOptions: {

        module: commonjs,

        outFile: ./build/local/tsc.js,

        sourceMap: true

    },

    exclude: [

        node_modules

    ]

}

Here we’re configuring the compiler in a number of ways. We’re specifying a module system to compile to, where to put the compiled file when it’s finished and to include a source map. We’re also giving it an exclude option, which basically tells the compiler to compile any TypeScript files — those ending in .ts — it finds as long as they’re not in the node_modules folder.

From here, we can integrate things into our favorite task runner or bundler. Both Grunt and Gulp have plugins for TypeScript which will expose the compiler options for your task runners. Webpack has an awesome TypeScript loader, and there’s good support for some other setups as well. Basically, you can get TypeScript integrated into pretty much any workflow you currently have going on without too much effort.

External Typings

If you’re using external libraries in your project (let’s be honest, who isn’t?) you’ll likely also need some type definitions. These definitions — denoted by a .d.ts extension — give us access to interfaces that other people have written for a number of JavaScript libraries. By and large, these definitions are available in a gigantic repo called DefinitelyTyped, which is where we install them from.

To use them you’ll need to install Typings, which is kind of like npm but for TypeScript type definitions. It has its own config file, called typings.json, where you can configure your bundles and paths for type definition installation.

We won’t go into too much detail here, but if we wanted to use AngularJS 1.x types, for example, we could simply go typings install angularjs --save and have them downloaded into a path defined in typings.json. After that, you could use Angular’s type definitions anywhere in your project simply by including this line:

/// angularjs/angular.d.ts />

Now we can use Angular type definitions like the following:

var http: ng.IHttpService;

Any developers who happen upon our code at a later stage (or ourselves, three months after we’ve written it) will be able to make more sense of what we’ve written by looking at them.

Okay, What About the Community?

The TypeScript community is continuing to grow, as is the language’s adoption. Perhaps most importantly, it’s what Angular is written in and the framework provides full support for it straight from the beginning. There is also fantastic support for its syntax baked into Microsoft Visual Studio IDE and Visual Studio Code, with packages and plugins for editors like Atom, Sublime Text and Emacs readily available as well.

What this means is that there’s plenty of activity going on around TypeScript, so this is something you’ll want to keep your eye on.

Further Reading

Official TypeScript site

DefinitelyTyped — 3rd-party TypeScript Definitions

Conclusion

TypeScript is an interesting push toward improving on JavaScript’s shortcomings by introducing a static typing system, complete with interfaces and type unions. This helps us write safer,