Switching to Angular - Third Edition

4.5 (2 reviews total)
By Minko Gechev
  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Switching to the One Angular

About this book

Align your work to stable APIs of Angular, version 5 and beyond, with Angular expert Minko Gechev. Angular is the modern Google framework for you to build high-performance, SEO-friendly, and robust web applications. Switching to Angular, Third Edition, shows you how you can align your current and future development with Google's long-term vision for Angular. Gechev shares his expert knowledge and community involvement to give you the clarity you need to confidently switch to Angular and stable APIs.

Minko Gechev helps you get to grips with Angular with an overview of the framework, and understand the long-term building blocks of Google's web framework. Gechev then gives you the lowdown on TypeScript with a crash course, so you can take advantage of Angular in its native, statically typed environment. You'll next move on to see how to use Angular dependency injection, plus how Angular router and forms, and Angular pipes, are designed to work for your projects today and in the future.

You'll be aligned with the vision and techniques of the one Angular, and be ready to start building quick and efficient Angular applications. You'll know how to take advantage of the latest Angular features and the core, stable APIs you can depend on. You'll be ready to confidently plan your future with the Angular framework.

Publication date:
October 2017
Publisher
Packt
Pages
280
ISBN
9781788620703

 

Chapter 1. Switching to the One Angular

Although the content of this book can be properly digested without any prior AngularJS or Angular experience, you will get most of the book if you are familiar with the basics of AngularJS and you are willing to switch to Angular.

On the internet, often AngularJS and Angular 1 are used interchangeably to refer to the AngularJS framework. This misconception leaves AngularJS experts confused about the Angular versioning. Very often, in many community events, I get questions similar to this one:

I just learnt Angular X, but I heard that Angular X+1 is coming in 6 months. Does this mean I should learn a new framework?

Here, you can replace X with any number bigger than 2.

The short answer to this question is: no, you don't have to learn a new framework when a new major version is released. In fact, the API deprecations between Angular 2 and Angular 5 can be listed on a few lines.

This confusion was brought mostly by incorrectly referring to AngularJS as Angular 1, which makes developers believe that every new version of Angular will be as different from the old one as Angular is from AngularJS.

Along the remaining sections of this chapter and in Chapter 2, Get Going with Angular, we will explain how Angular differs from AngularJS and why the development of a new framework was required.

 

Introducing the One Angular


Angular is a framework for application development. Its main focus is to provide a solid foundation for the development of the user interface of our applications.

One of the core primitives that the framework provides is its powerful dependency injection mechanism which allows us to easily control the relations between the individual building blocks of our code. Angular's obviously fast change detection provides a way to synchronize the views of our application with the current state of the data model. Being completely transparent to developers, the change detection knows exactly when the model has changed and performs the minimum set of operations in order to reflect the update in the view.

Being able to extend the valid HTML, Angular's templates with custom elements allow us to use a declarative Domain Specific Language (DSL) to express the structure of the user interface of our application and its bindings to the model.

Angular was inspired for all these ideas and many others by its predecessor, AngularJS.

 

From AngularJS to Angular


The initial release of AngularJS was on October 20, 2010. The framework nowadays is used in millions of applications around the world. AngularJS got so popular that numerous technologies were inspired by it and even started using it as a foundation.

One such platform for development of mobile applications is Ionic. Over time, the framework was constantly evolving, trying to provide an API as ergonomic and simplistic API as possible while still being powerful and expressive enough to help us develop complex web applications with ease. The API changes between versions were small and usually introduced through a deprecation process. This way, we: as developers: have enough time to go through the transition process and align to the latest changes.

In the meantime, however, the web evolved, and tens of new technologies got created, some of which directly impacted AngularJS itself or gave the framework opportunities for big jumps in terms of performance or ergonomics. Such new APIs were introduced, for example, by the web worker standard, or even new languages such as TypeScript.

This way, although AngularJS was the optimal technology for application development in 2010, it struggled to stay competitive and flawless, given the constantly moving web. This was the birth of the idea for a new framework, inspired by AngularJS, but with more powerful APIs and better performance! Because of the conceptual similarities with AngularJS, Google called this new framework Angular.

 

The new beginning


The team at Google, willing to take advantage of the most advanced technologies in Angular, decided to start with a solid, statically typed foundation in the face of TypeScript. On top of that, they considered variety of different ways for the improvement of Angular's performance in order to help developers deliver lightning fast experience to the users of our applications.

Given the learned lesson from AngularJS about the constantly evolving browser APIs, the Angular team developed the framework with a small core and a lot of different libraries surrounding it, providing extra features. This way, the framework's foundational APIs will be able to stay as immutable as possible and the entire infrastructure surrounding Angular's core will evolve following the well-defined release process of semantic versioning. You can see some of the modules developed around Angular core in the following figure:

Figure 1

We'll describe some of these modules in the upcoming chapters.

Before going any further, let's have an overview of what semantic versioning actually means.

 

Angular and SemVer


AngularJS was rewritten from scratch and replaced with its successor, Angular 2. A lot of us were bothered by this big step, which didn't allow us to have a smooth transition between these two versions of the framework. Right after Angular 2 was stable, Google announced that they wanted to follow the so called Semantic Versioning Specification (also known as SemVer).

SemVer defines the version of a given software project as the triple X.Y.Z, where Z is called patch version, Y is called minor version, and X is called major version. A change in the patch version means that there are no intended breaking changes impacting the public API surface between two versions of the same project, but only bug fixes. The minor version of a project will be incremented when new functionality is introduced, and there are no breaking changes. Finally, the major version will be increased when incompatible changes are introduced in the API.

This means that between versions 2.3.1 and 2.10.4, there are no introduced breaking changes, but only a few added features and bug fixes. However, if we have version 2.10.4 and we want to change any of the already existing public APIs in a backward-incompatible manner (for instance, changing the order of the parameters that a method accepts), we need to increment the major version and reset the patch and minor versions; so we will get version 3.0.0.

The Angular team also follows a strict, predictable schedule. According to it, a new patch version needs to be introduced every week; there should be three monthly minor releases after each major release, and finally, one major release every 6 months. This means that by the end of 2018, there will be Angular 7. However, this doesn't mean that every 6 months we'll have to go through the same migration path like we did between AngularJS and Angular 2. Not every major release will introduce breaking changes that are going to impact our projects. For instance, support for a newer version of TypeScript or change of the last optional argument of a method will be considered as a breaking change. We can think of these breaking changes in a way similar to what happened between AngularJS 1.2 and AngularJS 1.3.

Note

Since the content that you'll read in this book will be mostly relevant across different Angular versions, we'll refer to the framework as only Angular. If somewhere we explicitly mention a version, this doesn't mean that the given paragraph will not be valid for Angular 4 or Angular 5; it most likely will. If a given API is available in only a specific Angular version, this will be clearly noted. In case you're interested to know what the changes are between different versions of the framework, you can take a look at the change log at https://github.com/angular/angular/blob/master/CHANGELOG.md.

Now that we've introduced Angular's semantic versioning and conventions for referring to the different versions of the framework, we can officially start our journey!

 

Summary


In this chapter, we made an introduction of what Angular is. We explained that Angular and AngularJS are entirely different frameworks.

After that, we went through the basics of the structure of the framework: having a core with a minimalistic, immutable API and building on top of it with different modules in order to provide the best development experience possible.

Finally, we explained how Angular follows semantic versioning, which helps us understand why and when we should expect incompatible API changes in Angular.

In the next chapter, we'll focus on why AngularJS couldn't keep up with the constant evolution of the web, how Angular took advantage of the new, powerful browser API, and how it makes the development of large scale applications easier.

About the Author

  • Minko Gechev

    Minko Gechev is a Google Developer Expert for the Angular team and a presenter at over 40 worldwide conferences, including ng-conf, AngularConnect, AngularUP, and many others. Minko is co-author of the official Angular style guide, and has developed codelyzer – a tool for static analysis of Angular applications and best practices, which is part of the Angular CLI, and currently has over a million downloads each month.

    Minko is a former member of the Angular Mobile Team where his role involved him with tools for facilitating the process of developing Progressive web applications with Angular easier. Other projects by the author include the AngularJS style guide, which is translated to 13 different languages, aspect.js, Angular Seed, and many others.

    Minko Gechev is co-founder and CTO at Rhyme and strongly believes in open source software.

    Browse publications by this author

Latest Reviews

(2 reviews total)
Did not read it yet but I can already tell it's great!
I'm done .............................
Book Title
Access this book, plus 7,500 other titles for FREE
Access now