block includes
  include ../_util-fns
  - var _library_module = 'library module'
  - var _at_angular = '@angular'

block angular-intro
  :marked
    Angular is a framework for building client applications in HTML and
    either JavaScript or a language like TypeScript that compiles to JavaScript.

    The framework consists of several libraries, some of them core and some optional.

:marked
  You write Angular applications by composing HTML *templates* with Angularized markup,
  writing *component* classes to manage those templates, adding application logic in *services*,
  and boxing components and services in *modules*.
  
  Then you launch the app by *bootstrapping* the _root module_.
  Angular takes over, presenting your application content in a browser and
  responding to user interactions according to the instructions you've provided.

  Of course, there is more to it than this.
  You'll learn the details in the pages that follow. For now, focus on the big picture.

figure
  img(src="/resources/images/devguide/architecture/overview2.png" alt="overview" style="margin-left:-40px;" width="700")

:marked
  The architecture diagram identifies the eight main building blocks of an Angular application:

  * [Modules](#modules)
  * [Components](#components)
  * [Templates](#templates)
  * [Metadata](#metadata)
  * [Data binding](#data-binding)
  * [Directives](#directives)
  * [Services](#services)
  * [Dependency injection](#dependency-injection)

  Learn these building blocks, and you're on your way.

.l-sub-section
  p The code referenced on this page is available as a <live-example></live-example>.

.l-main-section
:marked
  ## Modules
figure
  img(src="/resources/images/devguide/architecture/module.png" alt="Component" align="left" style="width:240px; margin-left:-40px;margin-right:10px" )

block angular-modules
  :marked
    Angular apps are modular and Angular has its own modularity system called _Angular modules_ or _NgModules_.

    _Angular modules_ are a big deal. 
    This page introduces modules; the [Angular modules](ngmodule.html) page covers them in depth.

  <br class="l-clear-both"><br>
  :marked
    Every Angular app has at least one Angular module class, [the _root module_](appmodule.html "AppModule: the root module"),  
    conventionally named `AppModule`.

    While the _root module_ may be the only module in a small application, most apps have many more 
    _feature modules_, each a cohesive block of code dedicated to an application domain,
    a workflow, or a closely related set of capabilities. 

    An Angular module, whether a _root_ or _feature_, is a class with an `@NgModule` decorator.
  .l-sub-section
    :marked
      Decorators are functions that modify JavaScript classes.
      Angular has many decorators that attach metadata to classes so that it knows
      what those classes mean and how they should work.
      <a href="https://medium.com/google-developers/exploring-es7-decorators-76ecb65fb841#.x5c2ndtx0" target="_blank">
      Learn more</a> about decorators on the web.
  :marked
    `NgModule` is a decorator function that takes a single metadata object whose properties describe the module. 
    The most important properties are:
    * `declarations` - the _view classes_ that belong to this module.
    Angular has three kinds of view classes: [components](#components), [directives](#directives), and [pipes](pipes.html).

    * `exports` - the subset of declarations that should be visible and usable in the component [templates](#templates) of other modules.

    * `imports` - other modules whose exported classes are needed by component templates declared in _this_ module.

    * `providers` - creators of [services](#services) that this module contributes to
    the global collection of services; they become accessible in all parts of the app.

    * `bootstrap` - the main application view, called the _root component_, 
    that hosts all other app views. Only the _root module_ should set this `bootstrap` property.

    Here's a simple root module:
  +makeExample('src/app/mini-app.ts', 'module', 'src/app/app.module.ts')(format='.')

  .l-sub-section
    :marked
      The `export` of `AppComponent` is just to show how to export; it isn't actually necessary in this example. A root module has no reason to _export_ anything because other components don't need to _import_ the root module. 
  :marked
    Launch an application by _bootstrapping_ its root module. 
    During development you're likely to bootstrap the `AppModule` in a `main.ts` file like this one.
      
  +makeExample('src/main.ts', '', 'src/main.ts')(format='.')

  :marked
    ### Angular modules vs. JavaScript modules

    The Angular module &mdash; a class decorated with `@NgModule` &mdash; is a fundamental feature of Angular.

    JavaScript also has its own module system for managing collections of JavaScript objects.
    It's completely different and unrelated to the Angular module system.
    
    In JavaScript each _file_ is a module and all objects defined in the file belong to that module.
    The module declares some objects to be public by marking them with the `export` key word. 
    Other JavaScript modules use *import statements* to access public objects from other modules.

  +makeExample('src/app/app.module.ts', 'imports', '')(format='.')
  +makeExample('src/app/app.module.ts', 'export', '')(format='.')
    
  .l-sub-section
    :marked
      <a href="http://exploringjs.com/es6/ch_modules.html" target="_blank">Learn more about the JavaScript module system on the web.</a>
  :marked
    These are two different and _complementary_ module systems. Use them both to write your apps.

:marked
  ### Angular libraries

figure
  img(src="/resources/images/devguide/architecture/library-module.png" alt="Component" align="left" style="width:240px; margin-left:-40px;margin-right:10px" )

block angular-libraries
  :marked
    Angular ships as a collection of JavaScript modules. You can think of them as library modules. 

    Each Angular library name begins with the `!{_at_angular}` prefix.
    
    You install them with the **npm** package manager and import parts of them with JavaScript `import` statements.
    <br class="l-clear-both"><br>

    For example, import Angular's `Component` decorator from the `@angular/core` library like this:
  +makeExample('src/app/app.component.ts', 'import', '')(format='.')
  :marked
    You also import Angular _modules_ from Angular _libraries_ using JavaScript import statements:
  +makeExample('src/app/mini-app.ts', 'import-browser-module', '')(format='.')
  :marked
    In the example of the simple root module above, the application module needs material from within that `BrowserModule`. To access that material, add it to the `@NgModule` metadata `imports` like this.
  +makeExample('src/app/mini-app.ts', 'ngmodule-imports', '')(format='.')
  :marked
    In this way you're using both the Angular and JavaScript module systems _together_.

    It's easy to confuse the two systems because they share the common vocabulary of "imports" and "exports".
    Hang in there. The confusion yields to clarity with time and experience.

  .l-sub-section
    :marked
      Learn more from the [Angular modules](ngmodule.html) page.

.l-hr 

.l-main-section#components
:marked
  ## Components

figure
  img(src="/resources/images/devguide/architecture/hero-component.png" alt="Component" align="left" style="width:200px; margin-left:-40px;margin-right:10px" )

:marked
  A _component_ controls a patch of screen called a *view*.

  For example, the following views are controlled by components:

  * The app root with the navigation links.
  * The list of heroes.
  * The hero editor.

  You define a component's application logic&mdash;what it does to support the view&mdash;inside a class.
  The class interacts with the view through an API of properties and methods.

  <a id="component-code"></a>
  For example, this `HeroListComponent` has a `heroes` property that returns !{_an} !{_array} of heroes
  that it acquires from a service.
  `HeroListComponent` also has a `selectHero()` method that sets a `selectedHero` property when the user clicks to choose a hero from that list.

+makeExcerpt('src/app/hero-list.component.ts', 'class')
:marked
  Angular creates, updates, and destroys components as the user moves through the application.
  Your app can take action at each moment in this lifecycle through optional [lifecycle hooks](lifecycle-hooks.html), like `ngOnInit()` declared above.

.l-hr 

.l-main-section
:marked
  ## Templates
figure
  img(src="/resources/images/devguide/architecture/template.png" alt="Template" align="left" style="width:200px; margin-left:-40px;margin-right:10px" )
:marked
  You 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, except for a few differences. Here is a
  template for our `HeroListComponent`:

+makeExample('src/app/hero-list.component.html')

:marked
  Although this template uses typical HTML elements like `<h2>` and  `<p>`, it also has some differences. Code like `*ngFor`, `{{hero.name}}`, `(click)`, `[hero]`, and `<hero-detail>` uses Angular's [template syntax](template-syntax.html).


  In the last line of the template, the `<hero-detail>` tag is a custom element that represents a new component, `HeroDetailComponent`.
  
  The `HeroDetailComponent` is a *different* component than the `HeroListComponent` you've been reviewing.
  The `HeroDetailComponent` (code not shown) presents facts about a particular hero, the
  hero that the user selects from the list presented by the `HeroListComponent`.
  The `HeroDetailComponent` is a **child** of the `HeroListComponent`.

figure
  img(src="/resources/images/devguide/architecture/component-tree.png" alt="Metadata" align="left" style="width:300px; margin-left:-40px;margin-right:10px" )
:marked
  Notice how `<hero-detail>` rests comfortably among native HTML elements. Custom components mix seamlessly with native HTML in the same layouts.

<br class="l-clear-both">

.l-hr 

.l-main-section
:marked
  ## Metadata
figure
  img(src="/resources/images/devguide/architecture/metadata.png" alt="Metadata" align="left" style="width:150px; margin-left:-40px;margin-right:10px" )

:marked
<p style="padding-top:10px">Metadata tells Angular how to process a class.</p>
<br class="l-clear-both">
:marked
  [Looking back at the code](#component-code) for `HeroListComponent`, you can see that it's just a class.
  There is no evidence of a framework, no "Angular" in it at all.

  In fact, `HeroListComponent` really is *just a class*. It's not a component until you *tell Angular about it*.

  To tell Angular that `HeroListComponent` is a component, attach **metadata** to the class.

  In !{_Lang}, you attach metadata by using !{_a} **!{_decorator}**.
  Here's some metadata for `HeroListComponent`:

+makeExcerpt('src/app/hero-list.component.ts', 'metadata')

:marked
  Here is the `@Component` !{_decorator}, which identifies the class
  immediately below it as a component class.

block ts-decorator
  :marked
    The `@Component` decorator takes a required configuration object with the
    information Angular needs to create and present the component and its view.

    Here are a few of the possible `@Component` configuration options:

:marked
  <ul if-docs="ts"><li>`moduleId`: sets the source of the base address (`module.id`) for module-relative URLs such as the `templateUrl`.</ul>

  - `selector`: CSS selector that tells Angular to create and insert an instance of this component
  where it finds a `<hero-list>` tag in *parent* HTML.
  For example, if an app's  HTML contains `<hero-list></hero-list>`, then
  Angular inserts an instance of the `HeroListComponent` view between those tags.

  - `templateUrl`: module-relative address of this component's HTML template, shown [above](#templates).

block dart-directives

:marked
  - `providers`: !{_array} of **dependency injection providers** for services that the component requires.
  This is one way to tell Angular that the component's constructor requires a `HeroService`
  so it can get the list of heroes to display. 

figure
  img(src="/resources/images/devguide/architecture/template-metadata-component.png" alt="Metadata" align="left" style="height:200px; margin-left:-40px;margin-right:10px" )

:marked
  The metadata in the `@Component` tells Angular where to get the major building blocks you specify for the component.

  The template, metadata, and component together describe a view.

  Apply other metadata !{_decorator}s in a similar fashion to guide Angular behavior.
  `@Injectable`, `@Input`, and `@Output` are a few of the more popular !{_decorator}s.
<br class="l-clear-both">
:marked
  The architectural takeaway is that you must add metadata to your code
  so that Angular knows what to do.

.l-hr 

.l-main-section
:marked
  ## Data binding
  Without a framework, you would be responsible for pushing data values into the HTML controls and turning user responses
  into actions and value updates. Writing such push/pull logic by hand is tedious, error-prone, and a nightmare to
  read as any experienced jQuery programmer can attest.
figure
  img(src="/resources/images/devguide/architecture/databinding.png" alt="Data Binding" style="width:220px; float:left; margin-left:-40px;margin-right:20px" )
:marked
  Angular supports **data binding**,
  a mechanism for coordinating parts of a template with parts of a component.
  Add binding markup to the template HTML to tell Angular how to connect both sides.

  As the diagram shows, there are four forms of data binding syntax. Each form has a direction &mdash; to the DOM, from the DOM, or in both directions.
<br class="l-clear-both">
:marked
  The `HeroListComponent` [example](#templates) template has three forms:

+makeExcerpt('src/app/hero-list.component.1.html', 'binding')

:marked
  * The `{{hero.name}}` [*interpolation*](displaying-data.html#interpolation)
  displays the component's `hero.name` property value within the `<li>` element.

  * The `[hero]` [*property binding*](template-syntax.html#property-binding) passes the value of `selectedHero` from
  the parent `HeroListComponent` to the `hero` property of the child `HeroDetailComponent`.

  * The `(click)` [*event binding*](user-input.html#click) calls the component's `selectHero` method when the user clicks a hero's name.

  **Two-way data binding** is an important fourth form
  that combines property and event binding in a single notation, using the `ngModel` directive.
  Here's an example from the `HeroDetailComponent` template:

+makeExcerpt('src/app/hero-detail.component.html', 'ngModel')

:marked
  In two-way binding, a data property value flows to the input box from the component as with property binding.
  The user's changes also flow back to the component, resetting the property to the latest value,
  as with event binding.

  Angular processes *all* data bindings once per JavaScript event cycle,
  from the root of the application component tree through all child components.

figure
  img(src="/resources/images/devguide/architecture/component-databinding.png" alt="Data Binding" style="float:left; width:300px; margin-left:-40px;margin-right:10px" )
:marked
  Data binding plays an important role in communication
  between a template and its component.
<br class="l-clear-both">
figure
  img(src="/resources/images/devguide/architecture/parent-child-binding.png" alt="Parent/Child binding" style="float:left; width:300px; margin-left:-40px;margin-right:10px" )
:marked
  Data binding is also important for communication between parent and child components.
<br class="l-clear-both">

.l-hr 

.l-main-section
:marked
  ## Directives
figure
  img(src="/resources/images/devguide/architecture/directive.png" alt="Parent child" style="float:left; width:150px; margin-left:-40px;margin-right:10px" )
:marked
  Angular templates are *dynamic*. When Angular renders them, it transforms the DOM
  according to the instructions given by **directives**.

  A directive is a class with a `@Directive` !{_decorator}.
  A component is a *directive-with-a-template*;
  a `@Component` !{_decorator} is actually a `@Directive` !{_decorator} extended with template-oriented features.
  <br class="l-clear-both">

.l-sub-section
  :marked
    While **a component is technically a directive**,
    components are so distinctive and central to Angular applications that this architectural overview  separates components from directives.
:marked
  Two *other* kinds of directives exist: _structural_ and _attribute_ directives.

  They tend to appear within an element tag as attributes do,
  sometimes by name but more often as the target of an assignment or a binding.

  **Structural** directives alter layout by adding, removing, and replacing elements in DOM.

  The [example template](#templates) uses two built-in structural directives:

+makeExcerpt('src/app/hero-list.component.1.html', 'structural')

:marked
  * [`*ngFor`](displaying-data.html#ngFor) tells Angular to stamp out one `<li>` per hero in the `heroes` list.
  * [`*ngIf`](displaying-data.html#ngIf) includes the `HeroDetail` component only if a selected hero exists.

block dart-bool

:marked
  **Attribute** directives alter the appearance or behavior of an existing element.
  In templates they look like regular HTML attributes, hence the name.

  The `ngModel` directive, which implements two-way data binding, is
  an example of an attribute directive. `ngModel` modifies the behavior of
  an existing element (typically an `<input>`)
  by setting its display value property and responding to change events.

+makeExcerpt('src/app/hero-detail.component.html', 'ngModel')
:marked
  Angular has a few more directives that either alter the layout structure
  (for example, [ngSwitch](template-syntax.html#ngSwitch))
  or modify aspects of DOM elements and components
  (for example, [ngStyle](template-syntax.html#ngStyle) and [ngClass](template-syntax.html#ngClass)).

  Of course, you can also write your own directives. Components such as
  `HeroListComponent` are one kind of custom directive.
  <!-- PENDING: link to where to learn more about other kinds! -->

.l-hr 

.l-main-section
:marked
  ## Services
figure
  img(src="/resources/images/devguide/architecture/service.png" alt="Service" style="float:left; margin-left:-40px;margin-right:10px" )
:marked
  _Service_ is a broad category encompassing any value, function, or feature that your application needs.

  Almost anything can be a service.
  A service is typically a class with a narrow, well-defined purpose. It should do something specific and do it well.
<br class="l-clear-both">
:marked
  Examples include:
  * logging service
  * data service
  * message bus
  * tax calculator
  * application configuration

  There is nothing specifically _Angular_ about services. Angular has no definition of a service.
  There is no service base class, and no place to register a service.

  Yet services are fundamental to any Angular application. Components are big consumers of services.

  Here's an example of a service class that logs to the browser console:

+makeExcerpt('src/app/logger.service.ts', 'class')

:marked
  Here's a `HeroService` that uses a !{_PromiseLinked} to fetch heroes.
  The `HeroService` depends on the `Logger` service and another `BackendService` that handles the server communication grunt work.

+makeExcerpt('src/app/hero.service.ts', 'class')

:marked
  Services are everywhere.

  Component classes should be lean. They don't fetch data from the server,
  validate user input, or log directly to the console.
  They delegate such tasks to services.

  A component's job is to enable the user experience and nothing more. It mediates between the view (rendered by the template)
  and the application logic (which often includes some notion of a _model_).
  A good component presents properties and methods for data binding.
  It delegates everything nontrivial to services.

  Angular doesn't *enforce* these principles.
  It won't complain if you write a "kitchen sink" component with 3000 lines.

  Angular does help you *follow* these principles by making it easy to factor your
  application logic into services and make those services available to components through *dependency injection*.

.l-hr 

.l-main-section
:marked
  ## Dependency injection
figure
  img(src="/resources/images/devguide/architecture/dependency-injection.png" alt="Service" style="float:left; width:200px; margin-left:-40px;margin-right:10px" )
:marked
  _Dependency injection_ is a way to supply a new instance of a class
  with the fully-formed dependencies it requires. Most dependencies are services.
  Angular uses dependency injection to provide new components with the services they need.
<br class="l-clear-both">
:marked
  Angular can tell which services a component needs by looking at the types of its constructor parameters.
  For example, the constructor of your `HeroListComponent` needs a `HeroService`:

+makeExcerpt('src/app/hero-list.component.ts (constructor)', 'ctor')

:marked
  When Angular creates a component, it first asks an **injector** for
  the services that the component requires.

  An injector maintains a container of service instances that it has previously created.
  If a requested service instance is not in the container, the injector makes one and adds it to the container
  before returning the service to Angular.
  When all requested services have been resolved and returned,
  Angular can call the component's constructor with those services as arguments.
  This is *dependency injection*.

  The process of `HeroService` injection looks a bit like this:
figure
  img(src="/resources/images/devguide/architecture/injector-injects.png" alt="Service" )
:marked
  If the injector doesn't have a `HeroService`, how does it know how to make one?

  In brief, you must have previously registered a **provider** of the `HeroService` with the injector.
  A provider is something that can create or return a service, typically the service class itself.

block registering-providers
  :marked
    You can register providers in modules or in components.
    
    In general, add providers to the [root module](#module) so that
    the same instance of a service is available everywhere.

  +makeExcerpt('src/app/app.module.ts (module providers)', 'providers')

:marked
  Alternatively, register at a component level in the `providers` property of the `@Component` metadata:

+makeExcerpt('src/app/hero-list.component.ts (component providers)', 'providers')

:marked
  Registering at a component level means you get a new instance of the
  service with each new instance of that component.

  <!-- We've vastly oversimplified dependency injection for this overview.
  The full story is in the [dependency injection](dependency-injection.html) page. -->

  Points to remember about dependency injection:

  * Dependency injection is wired into the Angular framework and used everywhere.

  * The *injector* is the main mechanism.
    * An injector maintains a *container* of service instances that it created.
    * An injector can create a new service instance from a *provider*.

  * A *provider* is a recipe for creating a service.

  * Register *providers* with injectors.

.l-hr 

.l-main-section
:marked
  ## Wrap up

  You've learned the basics about the eight main building blocks of an Angular application:

  * [Modules](#modules)
  * [Components](#components)
  * [Templates](#templates)
  * [Metadata](#metadata)
  * [Data binding](#data-binding)
  * [Directives](#directives)
  * [Services](#services)
  * [Dependency injection](#dependency-injection)

  That's a foundation for everything else in an Angular application,
  and it's more than enough to get going.
  But it doesn't include everything you need to know.

  Here is a brief, alphabetical list of other important Angular features and services.
  Most of them are covered in this documentation (or soon will be).

  > [**Animations**](animations.html): Animate component behavior
  without deep knowledge of animation techniques or CSS with Angular's animation library.

  > **Change detection**: The change detection documentation will cover how Angular decides that a component property value has changed,
  when to update the screen, and how it uses **zones** to intercept asynchronous activity and run its change detection strategies.

  > **Events**: The events documentation will cover how to use components and services to raise events with mechanisms for
  publishing and subscribing to events.

  > [**Forms**](forms.html): Support complex data entry scenarios with HTML-based validation and dirty checking.

  > [**HTTP**](server-communication.html): Communicate with a server to get data, save data, and invoke server-side actions with an HTTP client.

  > [**Lifecycle hooks**](lifecycle-hooks.html): Tap into key moments in the lifetime of a component, from its creation to its destruction,
  by implementing the lifecycle hook interfaces.

  > [**Pipes**](pipes.html): Use pipes in your templates to improve the user experience by transforming values for display. Consider this `currency` pipe expression:
  >
  > > `price | currency:'USD':true`
  >
  > It displays a price of 42.33 as `$42.33`.

  > [**Router**](router.html): Navigate from page to page within the client
    application and never leave the browser.

block angular-feature-testing
  :marked
    > [**Testing**](testing.html): Run unit tests on your application parts as they interact with the Angular framework
    using the _Angular Testing Platform_.
