trackBy in an
ngFor block or a data table can often result in hard-to-track and seemingly glitchy behaviors in your web app. Today, I’ll discuss the signs that you need to use
trackBy. But first—some context:
More often than not, you’ll want to render some repeated element in Angular. You’ll see code that looks like this:
<ng-container *ngFor="let taskItem of getTasks(category)">
In cases where the
ngFor is looping over the results of a function that are created anew each time (e.g. an array being constructed using
.filter), you’ll run into some issues.
Every time the template is re-rendered, a new array is created with new elements. While newly-created array elements might be equivalent to the previous ones, Angular uses strict equality on each element to determine how to handle it.
In cases where the elements are an object type, strict equality will show that each element of the array is new. This means that a re-render would have a few side-effects:
- Angular determines all the old elements are no longer a part of the block, and
- destroys their components recursively,
- unsubscribes from all Observables accessed through an
| asyncpipe from within the
- Angular finds newly-added elements, and
- creates their components from scratch,
- subscribing to new Observables (i.e. by making a new HTTP request) to each Observable it accesses via an
This also leads to a bunch of state being lost:
- selection state inside the
ngForis lost on re-render,
- state like a link being in focus, or a text-box having filled-in values, would go away.
- if you have side-effects in your Observable pipes, you’ll see those happen again.
trackBy gives you the ability to define custom equality operators for the values you’re looping over. This allows Angular to better track insertions, deletions, and reordering of elements and components within an