include ../../../../_includes/_util-fns
:marked
Angular 2 is a framework to help us build client applications in HTML and JavaScript.
The framework consists of several cooperating libraries, some of them core and some optional.
We write applications by composing HTML *templates* with Angularized-markup,
writing *component* classes to manage those templates, adding application logic in *services*,
and handing the top root component to Angular's *bootstrapper*.
Angular takes over, presenting our application content in a browser and responding to user interactions
according to the instructions we provided.
:marked
Of course there is more to it than this.
We're cruising at high altitude in this overview.
We're looking for landmarks. We should expect the object below to be fuzzy and obscured by occasional clouds.
Details become more clear and precise when we land in the chapters themselves.
:marked
An Angular 2 application rests on eight main building blocks:
1. [Module](#module)
1. [Component](#component)
1. [Template](#template)
1. [Metadata](#metadata)
1. [Data Binding](#data-binding)
1. [Service](#service)
1. [Directive](#directive)
1. [Dependency Injection](#dependency-injection)
figure
img(src="/resources/images/devguide/architecture/overview2.png" alt="overview" style="margin-left:-40px;" width="700")
:marked
Learn these eight and we're on our way.
.l-sub-section
:marked
The code referenced in this chapter is available as a [live example](/resources/live-examples/architecture/ts/plnkr.html).
.l-main-section
:marked
## The Module
figure
img(src="/resources/images/devguide/architecture/module.png" alt="Component" align="left" style="width:240px; margin-left:-40px;margin-right:10px" )
:marked
Angular apps are modular.
In general we assemble our application from many **modules**.
A typical module is a cohesive block of code dedicated to a single purpose.
A module **exports** something of value in that code, typically one thing such as a class.
Perhaps the first module we meet is a module that exports a *component* class.
The component is one of the basic Angular blocks, we write a lot of them,
and we'll talk about components in the next segment. For the moment it is enough to know that a
component class is the kind of thing we'd export from a module.
Most applications have an `AppComponent`. By convention, we'll find it in a file named `app.component.ts`.
Look inside such a file and we'll see an `export` statement like this one.
+makeExample('architecture/ts/app/app.component.ts', 'export', 'app/app.component.ts (excerpt)')(format=".")
:marked
The `export` statement tells TypeScript that this is a module whose
`AppComponent` class is public and accessible to other modules of the application.
When we need a reference to the `AppComponent`, we **import** it like this:
+makeExample('architecture/ts/app/boot.ts', 'import', 'app/boot.ts (excerpt)')(format=".")
:marked
The `import` statement tells the system it can get an `AppComponent` from a module named `app.component`
located in a neighboring file.
The **module name** (AKA module id) is often the same as the filename without its extension.
### Library Modules
figure
img(src="/resources/images/devguide/architecture/library-module.png" alt="Component" align="left" style="width:240px; margin-left:-40px;margin-right:10px" )
:marked
Some modules are libraries of other modules.
Angular itself ships as a collection of library modules.
Each Angular library is actually a facade over several feature modules that belong together as a group.
The `angular2/core` library is the primary Angular library module from which we get most of what we need.
There are other important Angular library modules too such as `angular2/common`, `angular2/router`, and `angular2/http`.
We import what we need from an Angular library module in much the same way.
For example, we import the Angular **`Component` *function*** from the *angular2/core* module like this:
+makeExample('architecture/ts/app/app.component.ts', 'import')(format=".")
:marked
Compare that syntax to our previous import of `AppComponent`.
+makeExample('architecture/ts/app/boot.ts', 'import')(format=".")
:marked
Notice the difference?
In the first case, when importing from an Angular library module,
the import statement refers to the bare module name, `angular2/core`, *without a path prefix*.
When we import from one of *our* own files, we prefix the module name with the file path.
In this example we specify a relative file path (./). That means the
source module is in the same folder (./) as the module importing it.
We could path up and around the application folder structure if the source module were somewhere else.
.l-sub-section
:marked
We import and export in the ECMAScript 2015 (ES2015) module syntax.
Learn more about that syntax [here](http://www.2ality.com/2014/09/es6-modules-final.html)
and many other places on the web.
The infrastructure *behind* module loading and importing is an important subject.
But it's a subject outside the scope of this introduction to Angular.
While we're focused on our application, *import* and *export*
is about all we need to know.
:marked
The key take aways are:
* Angular apps are composed of modules.
* Modules export things — classes, function, values — that other modules import.
* We prefer to write our application as a collection of modules, each module exporting one thing.
The first module we write will most likely export a component.
.l-main-section
:marked
## The Component
:marked
A **Component** controls a patch of screen real estate that we could call a *view*.
The shell at the application root with navigation links, that list of heroes, the hero editor ...
they're all views controlled by Components.
We define a Component's application logic - what it does to support the view - inside a class.
The class interacts with the view through an API of properties and methods.
A `HeroListComponent`, for example, might have a `heroes` property that returns an array of heroes
that it acquired from a service.
It might have a `selectHero()` method that sets a `selectedHero` property when the user click on a hero from that list.
It might be a class like this:
+makeExample('architecture/ts/app/hero-list.component.ts', 'class', 'app/hero-list.component.ts')
:marked
Angular creates, updates, and destroys components as the user moves through the application.
The developer can take action at each moment in this lifecycle through optional [Lifecycle Hooks](#).
.l-sub-section
:marked
We're not showing those hooks in this example
but we are making a mental note to find out about them later.
We may wonder who is calling that constructor? Who provides the service parameter?
For the moment, have faith that Angular will call the constructor and deliver an
appropriate `HeroService` when we need it.
.l-main-section
:marked
## The Template
:marked
We define a Component's view with its companion **template**. A template is a form of HTML
that tells Angular how to render the Component.
A template looks like regular HTML much of the time ... and then it gets a bit strange. Here is a
template for our `HeroList` component.
+makeExample('architecture/ts/app/hero-list.component.html',null,'app/hero-list.component.html')
:marked
We recognize `
Metadata tells Angular how to process a class.