Expose NgForRow as a provider

I’m submitting a … (check one with “x”)

[ ] bug report => search github for a similar issue or PR before submitting
[x] feature request
[ ] support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Current behavior

import { NgForRow } from '@angular/common/src/directives/ng_for';
...
Object.defineProperties(NgForRow.prototype, { ... });

Expected behavior

import { NgForRow } from '@angular/common';
...
class CustomNgForRow extends NgForRow { ... }

@NgModule({
  providers: [{ provide: NgForRow, useValue: CustomNgForRow }], ...
})
class AppModule {}

Minimal reproduction of the problem with instructions

NgForRow has to be imported from @angular/common in order to be modified, yet the changes won’t be applied if pre-bundled modules are used (e.g. in Plunker).

import { NgForRow } from '@angular/common/src/directives/ng_for';
...
Object.defineProperties(NgForRow.prototype, {
  key: {
    get: function () {
      return this.$implicit[0];
    }
  },
  value: {
    get: function () {
      return this.$implicit[1];
    }
  }  
});

@Pipe({ name: 'entries' })
class EntriesPipe implements PipeTransform {
  transform(value) {
    return Object.entries(value);
  }
}

@Component({
  selector: 'app',
  template: `
      <div *ngFor="let heroEntry of heroFeats | entries; let hero = key; let feat = value">
        {{ hero }} saved the day from {{ feat.villain.name }}
      </div>`
})
AppComponent { ... }

What is the motivation / use case for changing the behavior?

Currently NgForRow modification results in hacking, the class isn’t injectable and has to be imported from internals. In order to provide extended behaviour to the directive, class prototype should be modified. Pre-bundled UMD Angular 2 modules won’t be affected with this hacky approach.

NgForRow is responsible for some ngFor behaviour and can be used to add new local variables, e.g. in order for #6663 to be addressed.

While not being limited to mentioned use case, the introduction of custom local variables with NgForRow allows to bring ng-repeat functionality to plain objects in cases where iteration order doesn’t matter.

Considering that deep object to array remapping may be impractical, the same snippet without custom locals results in less readable template, which may eventually worsen with nested iterated objects:

      <div *ngFor="let heroEntry of heroFeats | entries">
        {{ heroEntry[0] }} saved the day from {{ heroEntry[1].villain.name }}
      </div>

• Angular version: 2.2.X

• Browser: [all]

• Language: [all]

[bisubus]

@DzmitryShylovich That’s correct, I’ve found myself in the same boat with async iterated objects, though I believe there may be other valid cases for this subject.

I see some problems with the approach that @gdi2290 has shown, it looks like more like a workaround rather than a solution.

{{ key }} : {{ model[key] }} is less expressive than {{ key }} : {{ valueWithMeaningfulName }} , that’s why we’ve got Object.entries in addition to Object.keys.

Cluttering up component instance with temporary model/viewModel pairs doesn’t look tidy, async item that was provided through input should be wrapped with another observable. async pipe is cleaner and just does the job - when it is applicable.

Manually subscribed observables should be unsubscribed on destroy, something that async pipe takes care of.

[angular-automatic-lock-bot[bot]]

This issue has been automatically locked due to inactivity. Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}