When Angular evaluates {{name}}, it first looks at the scope associated with the given element for

the name property. If no such property is found, it searches the parent scope and so on until the
root scope is reached. In JavaScript this behavior is known as prototypical inheritance, and child
scopes prototypically inherit from their parents.

Data binding means that when you change something in the view,
the scope modelautomagically updates. Similarly, whenever the scope model changes, the view
updates itself with the new value. How does does AngularJS do that? When you write an expression
({{aModel}}), behind the scenes Angular sets up a watcher on the scope model, which in turn
updates the view whenever the model changes. This watcher is just like any watcher you set up in
AngularJS:

The normal flow of a browser receiving an event is that it executes a corresponding JavaScript
callback. Once the callback completes the browser re-renders the DOM and returns to waiting for
more events.

When the browser calls into JavaScript the code executes outside the Angular execution context,
which means that Angular is unaware of model modifications. To properly process model
modifications the execution has to enter the Angular execution context using the $applymethod.
Only model modifications which execute inside the $apply method will be properly accounted for by
Angular. For example if a directive listens on DOM events, such as ng-click it must evaluate the
expression inside the $apply method.

After evaluating the expression, the $apply method performs a $digest. In the $digest phase the
scope examines all of the $watchexpressions and compares them with the previous value. This dirty
checking is done asynchronously. This means that assignment such
as $scope.username="angular" will not immediately cause a $watch to be notified, instead
the $watch notification is delayed until the$digest phase. This delay is desirable, since it coalesces
multiple model updates into one $watch notification as well as guarantees that during
the $watch notification no other $watches are running. If a $watch changes the value of the model,
it will force additional$digest cycle.

Creation

The root scope is created during the application bootstrap by the $injector. During template linking,
some directives create new child scopes.

Watcher registration

During template linking, directives register watches on the scope. These watches will be used to
propagate model values to the DOM.

Model mutation

For mutations to be properly observed, you should make them only within the scope.$apply().
Angular APIs do this implicitly, so no extra $apply call is needed when doing synchronous work in
controllers, or asynchronous work with $http, $timeout or $intervalservices.

Mutation observation
At the end of $apply, Angular performs a $digest cycle on the root scope, which then propagates
throughout all child scopes. During the $digest cycle, all $watched expressions or functions are
checked for model mutation and if a mutation is detected, the $watch listener is called.

Scope destruction

When child scopes are no longer needed, it is the responsibility of the child scope creator to destroy
them via scope.$destroy() API. This will stop propagation of $digest calls into the child scope and
allow for memory used by the child scope models to be reclaimed by the garbage collector.

The second argument passed to $watch() is known as a listener function, and is called whenever the
value of aModel changes. It is easy for us to grasp that when the value of aModel changes this
listener is called, updating the expression in HTML. But, there is still one big question! How does
Angular figure out when to call this listener function? In other words, how does AngularJS know
when aModel changes so it can call the corresponding listener? Does it run a function periodically to
check whether the value of thescope model has changed? Well, this is where the $digest cycle steps
in.

It’s the $digest cycle where the watchers are fired. When a watcher is fired, AngularJS evaluates
thescope model, and if it has changed then the corresponding listener function is called. So, our next
question is when and how this $digest cycle starts.

digest cycle starts as a result of a call to $scope.$digest(). Assume that you change a scopemodel in a
handler function through the ng-click directive. In that case AngularJS automatically triggers
a $digest cycle by calling $digest(). When the $digest cycle starts, it fires each of the watchers. These
watchers check if the current value of the scope model is different from last calculated value. If yes,
then the corresponding listener function executes. As a result if you have any expressions in the view
they will be updated. In addition to ng-click, there are several other built-in directives/services that
let you change models (e.g. ng-model, $timeout, etc) and automatically trigger a $digest cycle.

So far, so good! But, there is a small gotcha. In the above cases, Angular doesn’t directly
call $digest(). Instead, it calls $scope.$apply(), which in turn calls $rootScope.$digest(). As a result of
this, a digest cycle starts at the $rootScope, and subsequently visits all the child scopes calling the
watchx`x`x`ers along the way.