Angular 2 Components: Practical and easy-to-follow guide to Angular 2 Components

This is an architectural design pattern for implementing user interfaces, which has been used for many years for desktop GUI.

It divides the application into three distinct parts:

The following diagram describes the relationships between those parts:

This pattern describes the communication between those parts. The view reflects the data in the model, but cannot alter the data directly in the model. It is common to describe the relationship between the model and the view as read only (the view can only read from the model). The view uses the controller by invoking methods and changing attributes. The controller updates the model, which causes the view to update and render the new data.

MVC, which was originally developed for desktop applications, has been widely adopted as an architecture for building single page web applications and can be found in all the popular client-side frameworks, including Angular.

Angular 1 implements a variation of the classic MVC, which is known by the name Model View ViewModel (MVVM). This pattern describes different roles and communication between the parts:

The following diagram describes the relationships between those parts with the terminology of Angular 1:

The ViewModel in Angular 1 is an object named: '$scope' that is constructed by an Angular controller. We do not always interact with this object directly. It's binding to the view is two-way (In Angular, we refer to the view as a 'Template'). The ViewModel can read and alter the data on the model and update itself when necessary. The view will reflect those changes immediately. Angular doesn't include any predefined model type. Instead, we code our models as plain JavaScript and register it as an Angular service. The following code snippet shows the structure of a custom model service Model.js:

class Product {
  constructor(){
    this.color = "red";
  }
}

The following code snippet shows the structure of ViewModel.js:

class ProductController {
  constructor(Product) {
    this.product = Product
  }
}

The following code snippet shows the structure of View.html:

<p>{{ product.color }}</p>

Angular applications are based around the concept of views. A view in Angular refers to a template (HTML), which is, most of the time, managed by one or more controllers. This view can also contain some custom directives that encapsulate some other chunks of HTML and JavaScript. Naturally, over the years, Angular developers tend to create more and more directives and use them as building blocks that replace the original HTML tags with custom elements.

The concept of composing a view from small custom elements has become trendy and can be found in other popular modern frameworks such as react and polymer. Angular 2 builds around this concept well and will base the UI architecture on those building blocks. Hence from now on, we call components as building blocks and templates as layouts.

Components are a clean way of organizing UI code into self-contained, reusable chunks, which contain their own view and logic. Components can be composed together to create a complex user interface. Components can optionally receive properties from the outside world and optionally communicate through callbacks or events. The business logic, structure and styling can be encapsulated inside the component code.

Components in Angular 2 are just directives with a view. Actually, the component in Angular 2 is a type of directive. We can also write a directive that doesn't include a template (and will not be called component) in Angular 2.

Those directives are very similar to the directives you're familiar with in Angular 1.x. The main difference is that in Angular 2.0 we think of two kinds of directives: attribute directives that add behavior to the elements, and structural directives which we named: components.

The angular 2 application is a set of components. We define a component for every UI element, view and route. We must define a root component that we will use as a container for all other components. In other words, an Angular 2 application is a tree of components.

The key for a well-designed, component-oriented Angular 2 application is to break the UI in to a tree of components successfully. For example, let's talk about a simple mobile to-do list application, which looks like this:

The components tree that composes this UI will look like this:

This application is made up of nine components. At the root is the Application component, which contains all the other components. Next, we find the Form component, which is built from an Input component and a Button component.

The TaskList component is a container for the TaskRow component. Each TaskRow comprises three components—a CheckBox, a Label, and a Trash icon.

There is no strict rule about how many components you should create, but a best practice is to break the UI to as many components as we can. The number of components will affect the other aspects of the application such as reusability, maintenance, and testing.

The idea of building a UI from components is not new. While in Angular 1 we had the ability to develop directives that act like components, it wasn't mandatory. In Angular 2, the whole application is a tree of components, so the ability to break your design into small parts and learn the how to build components is crucial.