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):

The browser loads the HTML and parses it into a DOM
The browser loads angular.js script
Angular waits for DOMContentLoaded event
Angular looks for ng-app directive, which designates the application boundary
The Module specified in ng-app (if any) is used to configure the $injector
The $injector is used to create the $compile service as well as $rootScope
The $compile service is used to compile the DOM and link it with $rootScope
The ng-init directive assigns World to the name property on the scope
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 <input> 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, class name or comment. 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.