12
votes

In Angular, is the trackBy function necessary for *ngFor? I saw a few articles here, here, here, and here that say using trackBy will improve performance and has better memory management. But I was wondering if trackBy is such an improvement, then why isn't it default behavior? Is it default behavior and everything I am looking at is out of date?

If it isn't default behavior, my project has about 90 *ngFor in 90 components and I was wondering if there was a way to use the trackBy where I am not including the following function 90 times. I also want to avoid adding a service and importing that 90 times.

HTML

<mat-option *ngFor="let l of list; trackBy: trackByFn" [value]="l.id">
   {{l.name}}
</mat-option>

TS

trackByFn(index, item) {
    return index
}
2

2 Answers

15
votes

notice that none of your examples use the index (besides one unreliable medium article), they all use a unique identifier of the object that angular can't possibly know unless you tell it.

Returning index alone has a use case but it's a fairly uncommon one. It's basically telling angular to never rerender the existing items in this list since the index of a given item will never change. This usually is a very unexpected behavior for developers since the initialization lifecycle hooks of sub components won't reexecute. This is generally safe to do though in ngFor's that don't have sub components but these kinds of lists are generally more performant anyway and you won't see much benefit unless the lists are very long or change frequently.

The idea of trackBy is to allow you to reinitialize items in lists that need it and not reinitialize ones that don't. It isn't a silver bullet for blindly increasing performance like some people treat it, it's purpose and functionality should be fully understood. Keep in mind that just because an item has a unique ID doesn't mean it is appropriate to use in a trackBy function. trackBy is meant to tell angular when an item needs to be re-rendered, ie when I need those life cycle hooks to re run. If the ID stays the same but the contents can change, depending on how you've built a certain component, that component might need to be reinitialized anyway.

4
votes

Give it a class for test

export class Item {
  id: number;
  name: string;
}

And add a directive to monitor its init and destory

@Directive({selector: '[appMonitor]'})
export class MonitorDirective implements OnInit, OnDestroy {


  ngOnInit(): void {
    console.log('init');
  }

  ngOnDestroy(): void {
    console.log('destroy');
  }
}

Init an arrary

  itemArray: Item[] = [
    {id: 1, name: 'Tom'},
    {id: 2, name: 'Joe'},
    {id: 3, name: 'KK'}
  ];

Two functions to change the array content

  allFoo(): void {
    this.itemArray = [
      {id: 1, name: 'Tom_foo'},
      {id: 2, name: 'Joe_foo'},
      {id: 3, name: 'KK_foo'}
    ];
  }

  allBar(): void {
    this.itemArray = [
      {id: 1, name: 'Tom_bar'},
      {id: 2, name: 'Joe_bar'},
      {id: 3, name: 'KK_bar'}
    ];
  }

The preparation is done,so far so good. First of all let's test without trackBy

  <div *ngFor="let item of itemArray " appMonitor>
    Id: {{item.id}} Name:{{item.name}}
  </div>

enter image description here

Clearlly every time you change the array angular has recreate component accordingly.Let's try trackBy this time:

<div *ngFor="let item of itemArray ;trackBy:identify" appMonitor>
  Id: {{item.id}} Name:{{item.name}}
</div>

Identity:

  identify(index: number, item: Item): number {
    return item.id;
  }

enter image description here

The component is being resued.So we can conclude that using trackBy can save the work from creating same component in hmtl.