### How Angular Works
In this chapter, we’re going to talk about the high-level concepts in Angular 2. The idea is that by taking a step back we can see how all the pieces fit together.
<table class="information sidebarish"><tbody><tr><td class="sidebar-icon"> <img class="sidebar-image" src="https://box.kancloud.cn/2015-07-14_55a489f6070c0.png" alt="information" width="50"/></td> <td> <p>If you’ve used Angular 1, you’ll notice that Angular 2 has a new mental-model for building applications. Don’t panic! As Angular 1 users we’ve found Angular 2 to be both straightforward and familiar. In the next chapter, we’re going to talk specifically about how to convert your Angular 1 apps to Angular 2.</p> </td> </tr></tbody></table>
In the chapters that follow we’ll be taking a deep dive into each concept, but here we’re just going to give an overview and explain the foundational ideas.
The first big idea is that an Angular 2 application is made up of _Components_. One way to think of Components is a way to teach the browser new tags. If you have an Angular 1 background, Components are analogous to _directives_ in Angular 1 (it turns out, Angular 2 has directives too, but we’ll talk more about this distinction later on).
However, ng2 Components have some significant advantages over ng1 directives and we’ll talk about that below. First, let’s start at the top: the Application.
### Application
An ng2 Application is nothing more than a tree of Components.
At the root of that tree, the top level Component is the application itself. And that’s what the browser will render when “booting” (a.k.a _bootstrapping_) the app.
One of the great things about Components is that they’re **composable**. This means that we can build up larger Components from smaller ones. The Application is simply a Component that renders other Components.
Because components are structured in a parent/child tree, when each Component renders, it recursively renders its children components.
For example, let’s talk about an imaginary inventory management application that is represented by the following page mockup:
Inventory Management App
Given this mockup, to write this application the first thing we’d to do is split it up into individual components (organized into a tree).
In this example, we could group the page into three high level components
1. The Navigation Component
1. The Breadcrumbs Component
1. The Product Info Component
The Navigation Component
This component would be render the navigation section. This would allow the user to visit other areas of the application.
Navigation Component
The Breadcrumbs Component
This would render a hierarchical representation of where in the application the user currently is.
Breadcrumbs Component
The Product List Component
The Products List component would be a representation of collection of products.
Product List Component
Breaking this component down into the next level of smaller components, we could say that the Product List is componse of multiple Product Rows.
Product Row Component
And of course, we could continue one step further, breaking each Product Row into smaller pieces:
- the **Product Image** component, that would be responsible to render a product image, given its image name (imagine that the component knows how to get the image using a proper Amazon S3 URL, for instance);
- the **Product Department** would have the responsability of, given a department id, render the whole department tree, like _Men > Shoes > Running Shoes_;
- the **Price Display** would be a more generic component, that could be reused accross the application, to properly render a price. Imagine that our implementation customizes the pricing if the user is logged in to include system-wide tier discounts or include shipping for instance. We could implement all this behavior into this component.
Finally, putting it all together into a tree representation, we end up with the following diagram:
App Tree Diagram
At the top we see **Inventory Management App**: that’s our application.
Under the application we have the Navigation, the Breadcrumb and the Products List components.
One important thing to note is that each application can only have one top level component.
### Components
As you can see, Components are the fundamental building block of Angular 2 applications. We break our application into more granular child components.
We’ll be using them a lot, so it’s worth looking at them more closely.
Each components is composed of three parts:
- Component _Decorator_
- A View
- A Controller
To illustrate the key concepts we need to understand about components, let’s focus on the **Products List** its child components:
Products List Component
An implementation of the Products List component could be:
~~~
1
~~~
~~~
// The "component decorator"
~~~
~~~
2
~~~
~~~
@
~~~
~~~
Component
~~~
~~~
({
~~~
~~~
3
~~~
~~~
selector:
~~~
~~~
'
~~~
~~~
products
~~~
~~~
-
~~~
~~~
list
~~~
~~~
',
~~~
~~~
4
~~~
~~~
properties:
~~~
~~~
{
~~~
~~~
5
~~~
~~~
products:
~~~
~~~
'
~~~
~~~
products
~~~
~~~
'
~~~
~~~
6
~~~
~~~
}
~~~
~~~
7
~~~
~~~
})
~~~
~~~
8
~~~
~~~
9
~~~
~~~
// The view annotation
~~~
~~~
10
~~~
~~~
@
~~~
~~~
View
~~~
~~~
({
~~~
~~~
11
~~~
~~~
directives:
~~~
~~~
[
~~~
~~~
ProductRow
~~~
~~~
],
~~~
~~~
12
~~~
~~~
template:
~~~
~~~
`
~~~
~~~
13
~~~
~~~
<
~~~
~~~
div
~~~
~~~
class
~~~
~~~
=
~~~
~~~
"products-list"
~~~
~~~
>
~~~
~~~
14
~~~
~~~
<
~~~
~~~
div
~~~
~~~
product
~~~
~~~
-
~~~
~~~
row
~~~
~~~
*
~~~
~~~
for
~~~
~~~
=
~~~
~~~
"#product in products"
~~~
~~~
[
~~~
~~~
product
~~~
~~~
]
~~~
~~~
=
~~~
~~~
"product"
~~~
~~~
>
~~~
~~~
15
~~~
~~~
</
~~~
~~~
div
~~~
~~~
>
~~~
~~~
16
~~~
~~~
</
~~~
~~~
div
~~~
~~~
>
~~~
~~~
17
~~~
~~~
`
~~~
~~~
18
~~~
~~~
})
~~~
~~~
19
~~~
~~~
20
~~~
~~~
// The "controller" class
~~~
~~~
21
~~~
~~~
class
~~~
~~~
ProductsList
~~~
~~~
{
~~~
~~~
22
~~~
~~~
products:
~~~
~~~
Array
~~~
~~~
<
~~~
~~~
Product
~~~
~~~
>
~~~
~~~
;
~~~
~~~
23
~~~
~~~
}
~~~
If you’ve been using Angular 1 the syntax might look pretty foreign! But the ideas are pretty similar, so let’s take them step by step:
Both the **component decorator** and the **view definition** sections are represented by **annotations**, however the **controller** is a represented by a **class**.
<table class="information sidebarish"><tbody><tr><td class="sidebar-icon"> <img class="sidebar-image" src="https://box.kancloud.cn/2015-07-14_55a489f683bcd.png" alt="information" width="50"/></td> <td> <p>Not sure how annotations work? Checkout the <a href="#typescript">Annotations Section in the Typescript Chapter</a></p> </td> </tr></tbody></table>
Let’s take a look into each part now in more detail.
### Component Decorator
The component decorator is where you declare how the outside world will interact with your component.
There are lots of options available to configure a component, which we cover in the Components chapter. Here we’re just going to touch on some of the basics.
#### Component `selector`
With the `selector` key, you indicate how your component will be recognized when rendering HTML templates. The idea is similar to, say, CSS or XPath selectors. The `selector` is a way to define what elements in the HTML will match this component. In this case, by saying `selector: 'products-list'`, we’re saying that in our HTML we want to match the `products-list` tag, that is, we’re defining a new tag that has built in functionality whenever we use it. E.g. when we put this in our HTML:
~~~
1
~~~
~~~
<products-list></products-list>
~~~
Angular will use the `ProductsList` component to implement the functionality.
Alternatively, with this selector, we can also use a regular `div` and specify the component as an attribute:
~~~
1
~~~
~~~
<div
~~~
~~~
products-list
~~~
~~~
></div>
~~~
#### Component `properties`
Our `@Component` annotation also has another key: `properties`. With `properties` we’re describing the configurable parameters we expect our component to receive. The idea here is that we can pass in an `Array` of `Product`s which this component will render.
You declare all the parameters your component expects to _receive_ from other components in the `properties` key.
`properties` takes a key-value object which should specify all “inputs” to this component. For instance we could have a different component that looks like this:
~~~
1
~~~
~~~
@
~~~
~~~
Component
~~~
~~~
({
~~~
~~~
2
~~~
~~~
//...
~~~
~~~
3
~~~
~~~
properties:
~~~
~~~
{
~~~
~~~
4
~~~
~~~
name:
~~~
~~~
'
~~~
~~~
name
~~~
~~~
'
~~~
~~~
,
~~~
~~~
5
~~~
~~~
age:
~~~
~~~
'
~~~
~~~
age
~~~
~~~
'
~~~
~~~
,
~~~
~~~
6
~~~
~~~
enabled:
~~~
~~~
'
~~~
~~~
isEnabled
~~~
~~~
'
~~~
~~~
7
~~~
~~~
}
~~~
~~~
8
~~~
~~~
//...
~~~
~~~
9
~~~
~~~
})
~~~
In the `properties` object, the key and the value have a specific meaning:
The **key** of the object (`name`, `age` and `enabled`) configures how the property is **visible to the outside world**.
The **values** (`name`, `age` and `isEnabled`) represent how that incoming property will be **visible (“bound”) in the controller**.
In this case, for `name` and `age` we used the same string for both key and value. However, for the property `enabled` we chose different values:`enabled` would be referred on the (incoming) view as `enabled` but it would be translated into a controller `isEnabled` property. We’ll see more examples of this shortly.
How the properties are exposed to the world is done on the View part of the component, as we’ll start learning now.
### Controller
The controller of a component is a class that **holds all the component properties** and contains the **implementation of behavior** that the component should have.
~~~
1
~~~
~~~
class
~~~
~~~
ProductsList
~~~
~~~
{
~~~
~~~
2
~~~
~~~
products
~~~
~~~
:
~~~
~~~
Array
~~~
~~~
<
~~~
~~~
Product
~~~
~~~
>
~~~
~~~
;
~~~
~~~
3
~~~
~~~
}
~~~
In this case, we’re specifying an instance variable of `products` which is an `Array` of `Product` objects. But in this example we’re not defining any behavior (we will before long).
### Views
You can think of the view as the visual part of the component. It is represented by the `@View` annotation and it declares the HTML template that the component will have.
~~~
1
~~~
~~~
// The view annotation
~~~
~~~
2
~~~
~~~
@
~~~
~~~
View
~~~
~~~
({
~~~
~~~
3
~~~
~~~
directives:
~~~
~~~
[
~~~
~~~
ProductRow
~~~
~~~
],
~~~
~~~
4
~~~
~~~
template:
~~~
~~~
`
~~~
~~~
5
~~~
~~~
<
~~~
~~~
div
~~~
~~~
class
~~~
~~~
=
~~~
~~~
"products-list"
~~~
~~~
>
~~~
~~~
6
~~~
~~~
<
~~~
~~~
div
~~~
~~~
product
~~~
~~~
-
~~~
~~~
row
~~~
~~~
*
~~~
~~~
for
~~~
~~~
=
~~~
~~~
"#product in products"
~~~
~~~
[
~~~
~~~
product
~~~
~~~
]
~~~
~~~
=
~~~
~~~
"product"
~~~
~~~
>
~~~
~~~
7
~~~
~~~
</
~~~
~~~
div
~~~
~~~
>
~~~
~~~
8
~~~
~~~
</
~~~
~~~
div
~~~
~~~
>
~~~
~~~
9
~~~
~~~
`
~~~
~~~
10
~~~
~~~
})
~~~
This `@View` annotation has many possible configuration options, but we’re using only two here:
- `directives`: This specifies the other components we want to be able to use in this view. This option takes an `Array` of classes. Unlike Angular 1, where all directives are essentially globals, in Angular 2 you must specifically say which directives you’re going to be using. Here we say we’re going to use the `ProductRow` directive.
- `template`: This specifies the HTML template that we want to use for rendering this component. Notice that we’re using TypeScript’s backtick ``` multi-line string syntax. Also you’ve probably noticed there is a lot of syntax in that view. We’ll go over each part in detail.
### Properties and Events
There are two more major concepts we need to be aware of to use components: **property bindings** and **event bindings**.
Data flows _in_ to your component via property bindings and _out_ of your component through event bindings.
That previous sentence is so important, it’s worth repeating:
<table class="information sidebarish"><tbody><tr><td class="sidebar-icon"> <img class="sidebar-image" src="https://box.kancloud.cn/2015-07-14_55a489f6c80af.png" alt="information" width="50"/></td> <td> <p>Data flows <strong>in</strong> to your component via <strong>property bindings</strong> and <strong>out</strong> of your component through <strong>event bindings</strong>.</p> </td> </tr></tbody></table>
Think of the set of property bindings + event bindings as defining the **public API** of your component.
**For “reading” data**Data in your component are available to the View by using property bindings. In our example above, we’re exposing our `products` array to the view by defining it as a property.
**For “writing” data**You application isn’t going to be read-only. There are also going to be inputs by the user. To handle an input from a user we use **events**.
For example, if we want to add some behavior when a button is clicked or a form is submitted, we _declare_ that intention on the View. That is, we add event bindings in our view. However, the actual implementation of handling that event takes place in the controller.
<table class="information sidebarish"><tbody><tr><td class="sidebar-icon"> <img class="sidebar-image" src="https://box.kancloud.cn/2015-07-14_55a489f6d7de6.png" alt="information" width="50"/></td> <td> <p>When talking about <em>properties</em>, the component decorator knows “what” properties exist and the view defines “how” they are rendered. When talking about <em>events</em>, it’s the other way around: the view knows “what” events will be triggered and the controller knows “how” they are handled.</p> </td> </tr></tbody></table>
#### Data binding
Let’s take a look at how our view can _bind_ to the component data by using properties. There are two ways our view can use properties.
##### Private Properties
The first way is to just inline the expression, for example:
~~~
1
~~~
~~~
@
~~~
~~~
View
~~~
~~~
({
~~~
~~~
2
~~~
~~~
template:
~~~
~~~
`
~~~
~~~
3
~~~
~~~
The
~~~
~~~
next
~~~
~~~
number
~~~
~~~
is
~~~
~~~
{{
~~~
~~~
number
~~~
~~~
+
~~~
~~~
1
~~~
~~~
}}
~~~
~~~
4
~~~
~~~
`
~~~
~~~
5
~~~
~~~
})
~~~
~~~
6
~~~
~~~
class
~~~
~~~
SomeComponent
~~~
~~~
{
~~~
~~~
7
~~~
~~~
number:
~~~
~~~
number
~~~
~~~
;
~~~
~~~
8
~~~
~~~
9
~~~
~~~
constructor
~~~
~~~
()
~~~
~~~
{
~~~
~~~
10
~~~
~~~
this
~~~
~~~
.
~~~
~~~
number
~~~
~~~
=
~~~
~~~
2
~~~
~~~
;
~~~
~~~
11
~~~
~~~
}
~~~
~~~
12
~~~
~~~
}
~~~
Here we are using the `number` property that the controller declared within an expression `{{ number + 1 }}`. That expression is then replaced when rendering the component. In our case it would render the `The next number is 3` text.
<table class="information sidebarish"><tbody><tr><td class="sidebar-icon"> <img class="sidebar-image" src="https://box.kancloud.cn/2015-07-14_55a489f6e5abf.png" alt="information" width="50"/></td> <td> <p>Using the <code>{{</code>…<code>}}</code> syntax is called template binding. It tells the view we want to use the value of the expression inside the brackets at this location in our template.</p> </td> </tr></tbody></table>
This previous example is an instance of a _controller-only property_. You can think of it as a private property for your component. A “private”, or controller-only, property is only visible within the component itself. Their commonly use for properties that are only used internally.
##### Public Properties
The second way to use an expression is by using a _component property_.
Contrasting with controller-only properties, the other type of property is a component properties. Component properties are declared **on the component decorator** and therefore made visible outside the component. You can think of these as “public” properties.
~~~
1
~~~
~~~
@
~~~
~~~
Component
~~~
~~~
({
~~~
~~~
2
~~~
~~~
selector:
~~~
~~~
'
~~~
~~~
some
~~~
~~~
-
~~~
~~~
component
~~~
~~~
'
~~~
~~~
,
~~~
~~~
3
~~~
~~~
properties:
~~~
~~~
{
~~~
~~~
4
~~~
~~~
number:
~~~
~~~
'
~~~
~~~
number
~~~
~~~
'
~~~
~~~
5
~~~
~~~
}
~~~
~~~
6
~~~
~~~
})
~~~
~~~
7
~~~
~~~
8
~~~
~~~
@
~~~
~~~
View
~~~
~~~
({
~~~
~~~
9
~~~
~~~
template:
~~~
~~~
`
~~~
~~~
10
~~~
~~~
The
~~~
~~~
next
~~~
~~~
number
~~~
~~~
is
~~~
~~~
{{
~~~
~~~
number
~~~
~~~
+
~~~
~~~
1
~~~
~~~
}}
~~~
~~~
11
~~~
~~~
`
~~~
~~~
12
~~~
~~~
})
~~~
~~~
13
~~~
~~~
class
~~~
~~~
SomeComponent
~~~
~~~
{
~~~
~~~
14
~~~
~~~
number:
~~~
~~~
number
~~~
~~~
;
~~~
~~~
15
~~~
~~~
}
~~~
In this example, we’re exposing a public property `number` which we allow to be passed in from an external component.
But now that we’ve exposed this property, how do we actually use it?
When using components you _bind_ values to properties using the `[property]="expression"` notation.
So say we wanted to pass a number to `SomeComponent` in a view, we could do the following:
~~~
1
~~~
~~~
<
~~~
~~~
some
~~~
~~~
-
~~~
~~~
component
~~~
~~~
[
~~~
~~~
number
~~~
~~~
]
~~~
~~~
=
~~~
~~~
'
~~~
~~~
41
~~~
~~~
'
~~~
~~~
>
~~~
And then our component would render `The next number is 42`.
The syntax for setting properties on components is the same whether we are using custom components or built-in components.
For instance, if we wanted our view to render an `input` tag with a `value` of the number, we could use the same property-setting notation:
~~~
1
~~~
~~~
@
~~~
~~~
View
~~~
~~~
({
~~~
~~~
2
~~~
~~~
template:
~~~
~~~
`
~~~
~~~
3
~~~
~~~
<
~~~
~~~
input
~~~
~~~
[
~~~
~~~
value
~~~
~~~
]
~~~
~~~
=
~~~
~~~
'
~~~
~~~
number
~~~
~~~
+
~~~
~~~
1
~~~
~~~
'
~~~
~~~
>
~~~
~~~
4
~~~
~~~
`
~~~
~~~
5
~~~
~~~
})
~~~
~~~
6
~~~
~~~
class
~~~
~~~
SomeComponent
~~~
~~~
{
~~~
~~~
7
~~~
~~~
number:
~~~
~~~
number
~~~
~~~
;
~~~
~~~
8
~~~
~~~
9
~~~
~~~
constructor
~~~
~~~
()
~~~
~~~
{
~~~
~~~
10
~~~
~~~
this
~~~
~~~
.
~~~
~~~
number
~~~
~~~
=
~~~
~~~
2
~~~
~~~
;
~~~
~~~
11
~~~
~~~
}
~~~
~~~
12
~~~
~~~
}
~~~
#### Event binding
In the last section we put data _in_ to our componentby using property binding. In this section, let’s look at how we get data _out_ of a component using events.
When you want to send data from your component to the outside world, you use _event bindings_.
Let’s say a component we’re writing has a button and we need to do something when that button is clicked.
The way to do this is by binding the _click_ event of the button to a method declared on our component’s controller. You do that using the `(event)="action"` notation.
Here’s an example where we keep a counter and increment (or decrement) based on which button is pressed:
~~~
1
~~~
@Component({...})
~~~
2
~~~
@View({
~~~
3
~~~
template: `
~~~
4
~~~
{{ value }}
~~~
5
~~~
~~~
<button
~~~
~~~
(click)="increase()"
~~~
~~~
>
~~~
Increase
~~~
</button>
~~~
~~~
6
~~~
~~~
<button
~~~
~~~
(click)="decrease()"
~~~
~~~
>
~~~
Decrease
~~~
</button>
~~~
~~~
7
~~~
`
~~~
8
~~~
})
~~~
9
~~~
class Counter {
~~~
10
~~~
value: number;
~~~
11
~~~
~~~
12
~~~
constructor() {
~~~
13
~~~
this.value = 1;
~~~
14
~~~
}
~~~
15
~~~
~~~
16
~~~
increase() {
~~~
17
~~~
this.value++;
~~~
18
~~~
}
~~~
19
~~~
~~~
20
~~~
decrease() {
~~~
21
~~~
this.value--;
~~~
22
~~~
}
~~~
23
~~~
}
In this example we’re saying that every time the first button is clicked, we want the `increase()` method on our controller to be invoked. And for when the second button clicked, we want to call the `decrease()` method.
The parentheses attribute syntax looks like this: `(event)="action"`. In this case, the event we’re listening for is `click` event on this button. There are many other events you can listen to: `mousedown`, `mousemove`, `dbl-click`, etc.
In this example, the event is internal to the component. When creating our own components we can also expose “public” events that allow the component to talk to the outside world. We’ll do that in the next example.
#### Putting it all together
Lets change the application example we used earlier in the chapter and allow our `ProductsList` component know when we click a given row. We could use this event to redirect to an individual product’s page.
In order for us to do that, let’s first address the the interaction of the `ProductsList` component and its children `ProductRow` components.
We’ll start by writing the `ProductRow` component:
~~~
1
~~~
@Component({
~~~
2
~~~
selector: 'product-row',
~~~
3
~~~
properties: {
~~~
4
~~~
product: 'product'
~~~
5
~~~
},
~~~
6
~~~
~~~
events: ['click']
~~~
~~~
7
~~~
})
~~~
8
~~~
@View({
~~~
9
~~~
template: `
~~~
10
~~~
~~~
`<div` `class=``"product-row"` `(click)="clicked()"``>`
~~~
~~~
11
~~~
~~~
<div
~~~
~~~
product-image
~~~
~~~
[product]="product"
~~~
~~~
>
~~~
~~~
12
~~~
~~~
</div>
~~~
~~~
13
~~~
~~~
<div
~~~
~~~
product-department
~~~
~~~
[department]="product.department_id"
~~~
~~~
>
~~~
~~~
14
~~~
~~~
</div>
~~~
~~~
15
~~~
~~~
<div
~~~
~~~
price-display
~~~
~~~
[price]="product.price"
~~~
~~~
>
~~~
~~~
16
~~~
~~~
</div>
~~~
~~~
17
~~~
~~~
</div>
~~~
~~~
18
~~~
`,
~~~
19
~~~
directives: [ProductImage, ProductDepartment, PriceDisplay]
~~~
20
~~~
})
~~~
21
~~~
class ProductRow {
~~~
22
~~~
product: Product;
~~~
23
~~~
click: EventEmitter;
~~~
24
~~~
~~~
25
~~~
constructor() {
~~~
26
~~~
~~~
this.click = new EventEmitter();
~~~
~~~
27
~~~
}
~~~
28
~~~
~~~
29
~~~
clicked() {
~~~
30
~~~
this.click.next(this.product);
~~~
31
~~~
}
~~~
32
~~~
}
There are a few things on `ProductRow` that looks new. Notice that we have a new `events` property on the component decorator: this is how you declare which custom events your component will trigger.
We are also now binding to the `click` event of our `product-row``div` in the `@View`, using `(click)="clicked()"`.
When this div is clicked, Angular 2 is going to call our controller’s `clicked()` method.
The missing piece here is how do we tell the ouside world that our component has been clicked. That’s where the `EventEmitter` class comes in.
As the name says, whenever our component wants to emit an event to the outside world, we will use this class.
So if you check our controller’s `clicked` method:
~~~
1
~~~
~~~
clicked
~~~
~~~
()
~~~
~~~
{
~~~
~~~
2
~~~
~~~
this
~~~
~~~
.
~~~
~~~
click
~~~
~~~
.
~~~
~~~
next
~~~
~~~
(
~~~
~~~
this
~~~
~~~
.
~~~
~~~
product
~~~
~~~
);
~~~
~~~
3
~~~
~~~
}
~~~
You can see that we are calling the `next` method of the `EventEmitter`, and passing the product this `ProductRow` holds. What we are doing is forwarding the event on to any one who is listening. This way, if we had another component that used ours, we could write:
~~~
1
~~~
~~~
<div
~~~
~~~
product-row
~~~
~~~
[product]="product"
~~~
~~~
(click)="display(product)"
~~~
~~~
>
~~~
~~~
2
~~~
~~~
</div>
~~~
Then, this component controller’s `display` method would be called when the `ProductRow` is clicked and the product would be passed to that method. Pretty neat.
#### Data Flow
So we can say that data would flow **from** the `ProductsList` and **in** to our `ProductRow` component by setting its `product` attribute:
Data Flowing Into ProductRow
And data would flow out of the `ProductRow` component and into the `ProductsList` by having the `ProductsList` component bind to the `ProductRow`’s click event like below:
Data Flowing Out from ProductRow
It’s important to know that data _binding_ is one way: from parent to child. This binding is automatic, but **one directional**. This differs from Angular 1, where data binding was bi-directional. It makes our program **much easier** to reason about. We’ll talk more about how to manage data in further chapters.
### Summary
In this chapter we learned that the core concept of Angular 2 is components. Any Angular 2 application is one component, composed of other smaller, more granular components.
Components are composed of three parts, which are the Component Decorator, a View and a Controller. The Component Decorator describes the configurable options of a component. In the View, we describe how the component will be rendered and which other components we’ll use while rendering. Finally, on the Controller is where you create the component behavior, or the business logic behind it.
In Angular 2 all bindings are one way only. This is a big difference from Angular 1, where all the bindings are bidirectional.
For this reason, components should receive data through properties and send data by using events. This way, other components can bind to those events and respond to them.
Now that we learned how Angular 2 works, let’s start looking into components in more detail.
