How to stop digest cycle manually in angularjs

Question

As digest cycle do the dirty checking of the variable that is if there are 100 scope variables and if I change one variable then it will run watch of all the variables.

Answer 1

This is a good question and highlights one of the biggest deficiencies with Angular 1.x. There is little control over how the digest cycle is managed. It is meant to be a black box and for larger applications, this can cause significant performance issues. There is no angular way of doing what you suggest, but There is something that would help you achieve the same goals (ie- better performance of the digest cycle when only one thing changes).

I recommend using the bind-notifier plugin. I have no relationship with the project, but I am using it for my own project and have had great success with it.

The idea behind is that you can specify certain bindings to only be $digested when a specific event has been raised.

There are multiple ways of using the plugin, but here is the one that I find must effective:

In a template file, specify a binding using the special bind-notifier syntax:

{{:user-data-change:user.name}}
{{:job-data-change:job.name}}

These two bindings will not be dirty-checked on most digest cycles unless they are notified.

In your controller, when user data changes, notify the bindings like this:

this.refreshUserData().then(() => {
  $scope.$broadcast('$$rebind::user-data-change');
});

(and similar for job-data-changed)

With this, the bindings for user.name will only be checked on the broadcast.

A few things to keep in mind:

1. This essentially subverts one of the key benefits of angular (also it's core weakness for large applications). Two way binding usually means that you don't need to actively manage changes to your model, but with this, you do. So, I would only recommend using this for the parts of your application that have lots of bindings and cause slowdowns.
2. $emit and $broadcast themselves can affect performance, so try to only call them on small parts of the $scope tree (scopes with few or no children).
3. Take a good look at the documentation since there are several ways to use the plugin. Choose the usage pattern that works best for your application.