Using AngularJS One-Time Binding (::) to Reduce Digest Overhead for Static Lists

Requirements

The goal is to lower the work AngularJS does during each $digest cycle when rendering large lists whose data never changes after the initial server response. Fewer watchers mean shorter digest loops and better UI responsiveness.

Smallest Suitable Design

Prefix any interpolation in the template with the one‑time binding syntax ::. AngularJS evaluates the expression once, assigns the value to the DOM, and then deregisters the watcher for that expression.

Template example

<ul>
  <li ng-repeat="item in ::items">
    {{ ::item.name }} – {{ ::item.value }}
  </li>
</ul>

The ::items tells AngularJS to watch the array only until its first stable value; the ::item.name and ::item.value bindings are evaluated once per element and then removed.

Trust / Data Boundaries

Treat the bound data as immutable after the first digest. Assume it originates from a trusted source (e.g., a REST response) and that no client‑side code will mutate those properties after the view is rendered. If the data can change, the one‑time binding must not be used.

Operational Checks

1. Render the page with the one‑time bindings in place.
2. Using the browser console, mutate the source model (e.g., $scope.items[0].name = 'changed').
3. Observe the DOM: the text should stay as it was after the first render.
4. Optionally inspect $scope.$$watchers.length before and after applying ::; a drop indicates watcher removal.

Failure Modes

If the underlying model is later altered (by user input, a service push, or a timer), the view will not reflect that change. The UI becomes stale, which can confuse users who expect the latest data.

Conditions That Would Change the Design

• The UI must show real‑time updates (e.g., live stock prices).
• Any field needs two‑way binding for editing (ng-model, ng-change, custom directives that write back).
• Third‑party directives rely on ongoing watchers to coordinate behavior.
• In these cases, revert to standard binding ({{ item.name }}) or use a scoped watcher explicitly.

Concrete Example

Consider a dashboard that displays a list of 500 configuration items fetched once at load time.

// Controller
app.controller('ConfigCtrl', function($scope, ConfigService) {
  ConfigService.getAll().then(function(data) {
    $scope.items = data; // array of {id, name, value}
  });
});

<!-- View -->
<div ng-controller="ConfigCtrl">
  <table>
    <thead>
      <tr><th>Name</th><th>Value</th></tr>
    </thead>
    <tbody>
      <tr ng-repeat="item in ::items">
        <td>{{ ::item.name }}</td>
        <td>{{ ::item.value }}</td>
      </tr>
    </tbody>
  </table>
</div>

After the initial digest, each ::item.name and ::item.value watcher is removed, leaving only the watcher for the ::items array (which itself disappears after the first stable value). The digest cycle now processes far fewer watchers.

Limitations

• One‑time binding cannot be used with directives that expect to write to the scope (ng-model, ng-change, custom isolate‑scoped components with =" bindings).
• If the data source is later replaced entirely (e.g., a new array assigned to $scope.items), the view will not update because the original array watcher is gone.
• Debugging tools that rely on watchers (such as Batarang) will show fewer entries; this is expected but may mask genuine watcher leaks elsewhere.

Verification Steps (to be performed by the developer)

1. Load the page with the one‑time bindings.
2. Open the console and execute $scope.items.push({id:999, name:'New', value:0}).
3. Confirm that the new row does not appear in the table.
4. Check $scope.$$watchers.length before adding the :: prefix and after; the count should be lower after the prefix is applied.
5. Remove the :: prefixes, repeat the push, and verify that the new row now appears, showing that normal binding is restored.