Introduction

Imagine, if you will, doing web development in an environment where you can control every aspect of the page you are building, and customize it to your heart’s content. Don’t like the white background on your page? You can change it easily using CSS. Want to react when your user moves into a field? You can hook into that event. It is a powerful environment—you develop your content, and can leave its presentation as is, or customize it as much as desired.

CSS styling

For example, the following line of CSS sets your document to an antique white background with a navy font color.

Code Listing 1

It’s powerful, quick, and easy!

JavaScript coding

You can hook into the event system just as easily by attaching event handlers to your elements.

Code Listing 2

Then, you add code to perform whatever function you would like.

Code Listing 3

Third-party libraries

Once you start working in this environment, you begin to realize there are subtle differences between CSS and JavaScript, depending on the browser the user is running. One approach is to attempt to code around these differences, but that adds more complexity to this environment. Fortunately, there are third-party libraries that hide that complexity from you by handling the browser differences internally.

So, to keep focused on your application, rather than browser differences, you come to rely on third-party software libraries like jQuery, Knockout, and Kendo UI.

The good

These third-party libraries hide this complexity and provide great functionality to make development much easier. For example, we can use jQuery’s on() function to hide the browser differences in event handling.

The bad

However, these third-party libraries have access to the very same elements on the page that you do. So your nice page with the antique white background might be changed to a dark color background because a library replaced your CSS class name with its own. Oh, and that JavaScript code you wrote when the button gets clicked? Well, it is possible a third-party library likes the function name ShowBtn(), so its method gets called instead of yours.

There are workarounds that most web developers are familiar with, such as loading libraries in a particular order, adding qualifier to all your class names and function calls, loading your CSS and JavaScript last, etc. Some even go as far as not relying on third-party libraries.

Why AngularJS?

AngularJS is an open-source JavaScript framework developed and maintained by Google, Inc. and several open-source contributors. It was originally released in 2009, primarily aimed at making the HTML syntax more capable for application development. It included concepts such as data binding and HTML templates. In its simplest form, an Angular application would consist of an HTML page (with imbedded “variables”) and a JavaScript object (called a controller) with properties and methods. The developer would manipulate the controller properties, and Angular would update the DOM (HTML page) to reflect the changing values.

Angular 2 was released in 2014 and rewritten to take advantage of new features that allow the development of components. It is a different approach to front-end development; instead of building a page and hoping your third-party libraries don’t conflict with your own code, you build components that will work the way you’d expect, and then use Angular to display the components to your user.

As we work through the book, we will develop components and use existing components to build our webpages. As Angular 2 continues to develop, you will see many third-party components that can be used in an Angular application. This will allow us to do front-end web development much like other environments, selecting the components we want to use and tying them together into an integrated product.

Angular 2

Angular 2 is a complete rewrite of the Angular library, and is not backwards compatible with Angular 1 applications. This caused some concern among developers, but the Angular team wanted to take advantage of many new features that were not around in 2009. Angular 2 is about making the most of the new browser developments to move forward and create better applications.

Some of the new web features that Angular 2 embraces are:

ECMAScript 6

ECMAScript is a scripting language specification standardized by ECMA International. JavaScript is one of the most popular implementations of ECMAScript for client-side web applications. It was first published in 1997, and has grown over the years. The most recent version (ES6) adds substantial syntax improvements for writing complex scripting applications. While not every browser supports all the new features, ECMAScript 6 is the future of JavaScript.

Note: You can read about ECMA6 in Matthew Duffield’s book ECMAScript 6 Succinctly, available from Syncfusion.

TypeScript

TypeScript is a superset of JavaScript developed and maintained by Microsoft. It adds features to JavaScript, most notably data types for variables. It also adds many of the features in ECMAScript 2015 (the scripting language most current browsers support). Angular 2 itself is written in TypeScript.

TypeScript files (.ts extension) are transpiled (meaning source code is converted to another source language) into JavaScript files (.js extension). This allows developers to use the features of TypeScript and still have browsers support and run the script.

We will use TypeScript in this book’s examples, but it’s okay if you are not familiar with the language. Knowing JavaScript and any object-oriented language (such as C#) will allow you to feel right at home with TypeScript. (Plus, Syncfusion has a book in the Succinctly series to help you learn it if needed.)

Dependency injection

Dependency injection is a software design pattern that attempts to reduce tightly coupled components by changing how component dependencies are handled. For example, if a logging component needs to notify users when something is amiss, it might be tempting to access another component (NotifyUsersByEMail, perhaps) within the logging component. While coding is a bit simpler, it creates a dependent relationship between the logging and the NotifyUsersByEMail component.

These dependencies make it difficult to test and debug components individually. For example, if you expect an event to be logged and users to be notified but it doesn’t happen, you need to determine if the mail component failed or the log component failed. Also, if the mail component changes, then the logging component must be updated to accommodate the changes.

A common approach to solving this is to write an interface that describes how the logging component plans to interact with the notification tasks it needs. Namely, it defines how to specify users, the subject and message, and how to invoke the send method. The logging component doesn’t know the details, just that it can access another object that matches the interface. The object itself gets passed into the component (often from the constructor) for the base component to use. The logging object doesn’t care about the particulars of the object, only that it has the agreed upon fields and methods.

Such an approach makes testing easier, and accommodates changes as well. For example, if we wrote a NotifyUsersBySMS object, as long as it offers the same methods as the Logging component expects, we can change the notification behavior simply by passing in a different component to the constructor.

Web components

Web components were first introduced in 2011, although components were a part of software development for many years prior to that. The standards necessary to implement web components are being worked on by the W3C, and they represent the future of web application development.

Without web components

When you develop front-end code, you are generally using some JavaScript framework, and possibly some CSS, sprinkling it through your HTML, and hoping that some subsequent CSS or JavaScript files don’t come along and change all the code you’ve written.

Recently, while working on a website, I found a JavaScript library that looked like it provided a solution to an issue. I added the library and the CSS files to my layout page, and got the functionality I wanted, with one nasty little side effect: the CSS changed all my <p> tags to be text-align: center.

Front-end development becomes a matter of carefully combining JavaScript and CSS libraries that hopefully don’t conflict with each other and produce the functionality we are trying to implement.

Web components

Web components are essentially fully encapsulated HTML elements that the browser knows how to display. Since the HTML and CSS are encapsulated in the component, the component will always display the way it was designed, even if some later-loaded CSS style sheet changes the presentation rules on HTML elements.

When you create an HTML page, you are creating the Document Object Model (DOM). The DOM is a representation of your HTML (or XML, etc.) source code as a nested tree structure. Browsers use various layout engines (such as WebKit or Gecko) to handle parsing the HTML into a DOM. Once the DOM is built, JavaScript and CSS can manipulate the DOM. If you’ve worked with jQuery or CSS, you’ve certainly seen selectors such as # (ID) or . (class) to get particular DOM elements.

Shadow DOM

The Shadow DOM is an encapsulated DOM object that can be created from any existing DOM element. The DOM element that creates the Shadow DOM is known as the ShadowHost. The new element is referred to as the ShadowRoot. The following JavaScript fragment shows how to create a Shadow DOM element.

Code Listing 4

Markup in the Shadow Root is not visible to the scripts outside of the Shadow DOM. The purpose of the Shadow DOM is to provide an encapsulated snippet, safe from prying eyes.

If you explore the following example in Code Listing 5, you see that the HTML element contains Hello, world. However, the script creates a ShadowRoot (if it does not yet exist) and sets the innerHTML to "Hello from Angular 2". When the browser executes this code, the button’s inner content gets replaced with whatever content is in the ShadowRoot.

Code Listing 5

However, when you click the button, the ShowBtn() function shows the content Hello, world, not the content that the browser displayed from the ShadowRoot. This is an example of the encapsulation and scoping necessary to build web components.

Note: Some browsers expose parts of the Shadow DOM to CSS through special pseudo-selectors. Also, component authors can choose to expose some content, particularly theming and styling, if they want to.

Template tag

Another piece of the component puzzle is the HTML <template> tag. This tag allows us to build HTML fragments for later use. Content inside a template tag will not display, and is not active (images won’t be downloaded, scripts won’t run, etc.).

Templates can contain HTML, CSS style sheets, and even JavaScript. They can be placed anywhere with the DOM, and stay inactive until you need them. The following is a simple template that draws a border and shadow around an <h3> element and adds some text.

Code Listing 6

Now, when we create our Shadow Root, rather than rely on manipulating the innerHTML property, we will plug the template code in. And the <h3> style within our template, since it is in the Shadow Root, will not impact any other <h3> styling the page might be using.

Code Listing 7

We grab the template element (we can use getElementById() if we have a number of different templates) and append it into the Shadow Root element. Our screen will now show the following in the HostDiv element.

Figure 1: Shadow Root

Getting content from the host

Often, our template code will want to get its content from the host element, rather than hard-coding the content in the template code. For example, if our Shadow Host element looked like the following:

Code Listing 8

We could replace our template’s HTML line:

Code Listing 9

with the following fragment:

Code Listing 10

When the template is inserted, it will grab the content of the Shadow Host’s <span> tag and use it instead.

Figure 2: Content from Shadow Host

Taken together, the Shadow DOM and the template system open the door to allow components within the front-end development of webpages. And that is one of the biggest benefits Angular 2 provides.

Summary

Angular 2 takes advantage of advantage of web components and the Shadow DOM to support component-driven development. In the rest of the book, we will use the Angular 2 framework to create a component-driven application, and perhaps along the way, create some reusable components for other applications.

Note: The code samples in this book are available for download at https://bitbucket.org/syncfusiontech/angular-2-succinctly.