I'm using *ngFor to populate options of <select></select>. My issue is that I can have 1000 array values for 1 of my 6 <select>. Performance is suffering. I know it's because of changeDetection or One-way Binding. Is there a way to better implement *ngFor for <option>. I don't actually need change detection or one-way binding.
My Code
<select [formControl]="requestForm.controls['SellCommodityId']">
<option [value]="" disabled selected>COMMODITY/GRADE</option>
<option [value]="item.Id" *ngFor="let item of fieldOptions?.Product;">{{item.Value}}</option>
</select>
UPDATE 12-20-2016
I placed the select into it's one Component like this:
import { Component, ChangeDetectionStrategy,Input } from '@angular/core';
/**
* <ihda-select [list]="list" [control]="control" [titleOption]="title"></ihda-select>
*/
@Component({
selector:'ihda-select',
changeDetection:ChangeDetectionStrategy.OnPush,
template:`
<select [formControl]="control" class="form-control">
<option [value]="" disabled selected>{{titleOption}}</option>
<option [value]="item.Id" *ngFor="let item of list">{{item.Value}}</option>
</select>
`,
styleUrls: ['../app.component.css']
})
export class IHDASelect{
@Input() list: any[];
@Input() control: any;
@Input() titleOption: string;
}
Performance issue persisted.
It seems like it wasn't the changeDetection, because i tried removing the [formControl] attribute from the <select> and then there was no longer a performance issue. It seems that using the [formControl] attribute here to track it for the form group causes the performance issue. Is there information about this? or how I may fix it?
UPDATE 12-21-2016
Performance Issue shown in the plunker here:
https://plnkr.co/edit/2jNKFotBRIIytcmLto7y?p=preview
If you click the Options Route it will take a long time to load the options. If you remove the form code the route doesn't take a long time to load.
When the
Optionsroute is selected all<options>for all<select>are rendered in one go before the application responds again.To avoid that the rendering of the
<options>could be delayed so that they are only rendered on demandhttps://plnkr.co/edit/KRgYHktFXHyPugS3nPQk?p=preview
The strategy can be further optimized so that
hasFocusis set totruedelayed by a timer after the component is already shown for one<select>at a time, so that while the browser is idle it already renders the<option>s.