# `Conceptual Overview`

# Overview

This document gives a quick overview of the main angular components and how they work together. These are:

- startup - bring up hello world
- runtime - overview of angular runtime
- scope - the glue between the view and the controller
- controller - application behavior
- model - your application data
- view - what the user sees
- directives - extend HTML vocabulary
- filters - format the data in user locale
- injector - assembles your application
- module - configures the injector
- `$` - angular namespace

# Startup

This is how we get the ball rolling (refer to the diagram and example below):

1. The browser loads the HTML and parses it into a DOM
2. The browser loads `angular.js` script
3. Angular waits for `DOMContentLoaded` event
4. Angular looks for `ng-app` directive, which designates the application boundary
5. The Module specified in `ng-app` (if any) is used to configure the `$injector`
6. The `$injector` is used to create the `$compile` service as well as `$rootScope`
7. The `$compile` service is used to compile the DOM and link it with `$rootScope`
8. The `ng-init` directive assigns `World` to the `name` property on the scope
9. The `{{name}}` `interpolates` the expression to `Hello World!`

### Source

### Demo

# Runtime

The diagram and the example below describe how Angular interacts with the browser's event loop.

1. The browser's event-loop waits for an event to arrive. An event is a user interaction, timer event, or network event (response from a server).
2. The event's callback gets executed. This enters the JavaScript context. The callback can modify the DOM structure.
3. Once the callback executes, the browser leaves the JavaScript context and re-renders the view based on DOM changes.

Angular modifies the normal JavaScript flow by providing its own event processing loop. This splits the JavaScript into classical and Angular execution context. Only operations which are applied in Angular execution context will benefit from Angular data-binding, exception handling, property watching, etc... You can also use $apply() to enter Angular execution context from JavaScript. Keep in mind that in most places (controllers, services) $apply has already been called for you by the directive which is handling the event. An explicit call to $apply is needed only when implementing custom event callbacks, or when working with third-party library callbacks.

1. Enter Angular execution context by calling scope `.` `$apply` `(stimulusFn)` . Where `stimulusFn` is the work you wish to do in Angular execution context.
2. Angular executes the `stimulusFn()` , which typically modifies application state.
3. Angular enters the `$digest` loop. The loop is made up of two smaller loops which process `$evalAsync` queue and the `$watch` list. The `$digest` loop keeps iterating until the model stabilizes, which means that the `$evalAsync` queue is empty and the `$watch` list does not detect any changes.
4. The `$evalAsync` queue is used to schedule work which needs to occur outside of current stack frame, but before the browser's view render. This is usually done with `setTimeout(0)` , but the `setTimeout(0)` approach suffers from slowness and may cause view flickering since the browser renders the view after each event.
5. The `$watch` list is a set of expressions which may have changed since last iteration. If a change is detected then the `$watch` function is called which typically updates the DOM with the new value.
6. Once the Angular `$digest` loop finishes the execution leaves the Angular and JavaScript context. This is followed by the browser re-rendering the DOM to reflect any changes.

Here is the explanation of how the `Hello world` example achieves the data-binding effect when the user enters text into the text field.

1. During the compilation phase:
   1. the `ng-model` and `input` directive set up a `keydown` listener on the `` control.
   2. the `{{name}}` interpolation sets up a `$watch` to be notified of `name` changes.
2. During the runtime phase:
   1. Pressing an ' `X` ' key causes the browser to emit a `keydown` event on the input control.
   2. The `input` directive captures the change to the input's value and calls `$apply` `("name = 'X';")` to update the application model inside the Angular execution context.
   3. Angular applies the `name = 'X';` to the model.
   4. The `$digest` loop begins
   5. The `$watch` list detects a change on the `name` property and notifies the `{{name}}` interpolation, which in turn updates the DOM.
   6. Angular exits the execution context, which in turn exits the `keydown` event and with it the JavaScript execution context.
   7. The browser re-renders the view with update text.

### Source

### Demo

# Scope

The scope is responsible for detecting changes to the model section and provides the execution context for expressions. The scopes are nested in a hierarchical structure which closely follow the DOM structure. (See individual directive documentation to see which directives cause a creation of new scopes.)

The following example demonstrates how the `name` expression will evaluate into a different value depending on which scope it is evaluated in. The example is followed by a diagram depicting the scope boundaries.

### Source

### Demo

# Controller

A controller is the code behind the view. Its job is to construct the model and publish it to the view along with callback methods. The view is a projection of the scope onto the template (the HTML). The scope is the glue which marshals the model to the view and forwards the events to the controller.

The separation of the controller and the view is important because:

- The controller is written in JavaScript. JavaScript is imperative. Imperative is a good fit for specifying application behavior. The controller should not contain any rendering information (DOM references or HTML fragments).
- The view template is written in HTML. HTML is declarative. Declarative is a good fit for specifying UI. The View should not contain any behavior.
- Since the controller is unaware of the view, there could be many views for the same controller. This is important for re-skinning, device specific views (i.e. mobile vs desktop), and testability.

### Source

### Demo

# Model

The model is the data which is merged with the template to produce the view. To be able to render the model into the view, the model has to be able to be referenced from the scope. Unlike many other frameworks Angular makes no restrictions or requirements on the model. There are no classes to inherit from or special accessor methods for accessing or changing the model. The model can be primitive, object hash, or a full object Type. In short the model is a plain JavaScript object.

# View

The view is what the user sees. The view begins its life as a template, is merged with the model and finally rendered into the browser DOM. Angular takes a very different approach to rendering the view compared to most other templating systems.

- Others - Most templating systems begin as an HTML string with special templating markup. Often the template markup breaks the HTML syntax which means that the template can not be edited by an HTML editor. The template string is then parsed by the template engine, and merged with the data. The result of the merge is an HTML string. The HTML string is then written to the browser using the `.innerHTML` , which causes the browser to render the HTML. When the model changes the whole process needs to be repeated. The granularity of the template is the granularity of the DOM updates. The key here is that the templating system manipulates strings.
- Angular - Angular is different, since its templating system works on DOM objects not on strings. The template is still written in an HTML string, but it is HTML (not HTML with template sprinkled in.) The browser parses the HTML into the DOM, and the DOM becomes the input to the template engine known as the `compiler`. The compiler looks for directives which in turn set up `watches` on the model. The result is a continuously updating view which does not need template model re-merging. Your model becomes the single source-of-truth for your view.

### Source

### Demo

# Directives

A directive is a behavior or DOM transformation which is triggered by the presence of a custom attribute, element name, or a class name. A directive allows you to extend the HTML vocabulary in a declarative fashion. Following is an example which enables data-binding for the `contenteditable` in HTML.

### Source

### Demo

# Filters

`Filters` perform data transformation. Typically they are used in conjunction with the locale to format the data in locale specific output. They follow the spirit of UNIX filters and use similar syntax `|` (pipe).

### Source

### Demo

# Modules and the Injector

The `injector` is a service locator. There is a single `injector` per Angular `application`. The `injector` provides a way to look up an object instance by its name. The injector keeps an internal cache of all objects so that repeated calls to get the same object name result in the same instance. If the object does not exist, then the `injector` asks the instance factory to create a new instance.

A `module` is a way to configure the injector's instance factory, known as a `provider`.

      // Create a module
      var myModule = angular.module('myModule', [])

      // Configure the injector
      myModule.factory('serviceA', function() {
        return {
          // instead of {}, put your object creation here
        };
      });

      // create an injector and configure it from 'myModule'
      var $injector = angular.injector(['myModule']);

      // retrieve an object from the injector by name
      var serviceA = $injector.get('serviceA');

      // always true because of instance cache
      $injector.get('serviceA') === $injector.get('serviceA');

But the real magic of the `injector` is that it can be used to `call` methods and `instantiate` types. This subtle feature is what allows the methods and types to ask for their dependencies instead of having to look for them.

      // You write functions such as this one.
      function doSomething(serviceA, serviceB) {
        // do something here.
      }

      // Angular provides the injector for your application
      var $injector = ...;

      ///////////////////////////////////////////////
      // the old-school way of getting dependencies.
      var serviceA = $injector.get('serviceA');
      var serviceB = $injector.get('serviceB');

      // now call the function
      doSomething(serviceA, serviceB);

      ///////////////////////////////////////////////
      // the cool way of getting dependencies.
      // the $injector will supply the arguments to the function automatically
      $injector.invoke(doSomething); // This is how the framework calls your functions

Notice that the only thing you needed to write was the function, and list the dependencies in the function arguments. When angular calls the function, it will use the `call` which will automatically fill the function arguments.

Examine the `ClockCtrl` below, and notice how it lists the dependencies in the constructor. When the `ng-controller` instantiates the controller it automatically provides the dependencies. There is no need to create dependencies, look for dependencies, or even get a reference to the injector.

### Source

### Demo

# Angular Namespace

To prevent accidental name collision, Angular prefixes names of objects which could potentially collide with `$` . Please do not use the `$` prefix in your code as it may accidentally collide with Angular code.