ngValue ignored in ng-content and ng-template

I’m submitting a…

[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report  
[ ] Performance issue
[x] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question
[ ] Other... Please describe:

This issue was previously reported at https://github.com/angular/angular/issues/22374, which was closed as a support request even though I don’t believe it was intended to be one.

Current behavior

ngValue is ignored if (1) the <option>s are provided via <ng-content> to a component (even if the component simply wraps a vanilla <select>) or (2) if the <option>s are in an <ng-template>.

Expected behavior

ngValue should work the same in these cases as it does when using a plain <select> with directly nested <option>s.

Minimal reproduction of the problem with instructions

Please see https://codesandbox.io/s/2z2n2v0pjp .

Here is a screenshot of the reproduction:

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

Many applications require a custom-styled <select> component that allow the caller of the component to provide their own <option>s.

Environment

Angular version: 6

Browser:
- [x] All

[pauldraper]

ngValue relies on DI of SelectControlValueAccessor.

Both failing examples the repro have the templated options defined outside any injector with SelectControlValueAccessor.

---

There is one case that will work, however. If SelectWrappedComponent provides SelectControlValueAccessor and the options are defined in its content, then it works.

I.e. This gives you the ability to write a decorated/custom select component with content-projected options that work well with ngModel/ngValue.

https://codesandbox.io/s/jrjnlvxl5

import { Component, forwardRef } from "@angular/core";
import { SelectControlValueAccessor, NG_VALUE_ACCESSOR } from "@angular/forms";

/** For simplicity, hackishly extend SelectControlValueAccessor to reuse its implementation. */
@Component({
  selector: "select-wrapped",
  template: `
    <select
      [selectedIndex]="properties.selectedIndex"
      [value]="properties.value"
      [disabled]="properties.disabled"
      [(ngModel)]="value"
      (blur)="onTouched()"
      (change)="onChange($event.target.value)"
    >
      <ng-content></ng-content>
    </select>
  `,
  styles: [],
  providers: [
    {
      provide: NG_VALUE_ACCESSOR,
      multi: true,
      useExisting: forwardRef(() => SelectWrappedComponent)
    },
    {
      provide: SelectControlValueAccessor,
      useExisting: forwardRef(() => SelectWrappedComponent)
    }
  ]
})
export class SelectWrappedComponent extends SelectControlValueAccessor {
  readonly properties;

  constructor() {
    super(
      <any>{
        setProperty(_, property, value) {
          this.properties = this.properties || {};
          this.properties[property] = value;
        }
      },
      {}
    );
    this.properties = this.properties || {};
  }
}

<select-wrapped [(ngModel)]="bin">
	<option [ngValue]="42">forty two (this value should be the number 42)</option>
	<option [ngValue]="43">forty three (this value should be the number 43)</option>
	<option [ngValue]="{ test: true }">test (this value should be an object)</option>
</select-wrapped>

[dylhunn]

We looked at this again today. This is generally related to the lack of a robust composability model in Forms. Solving that general issue would also solve this one. The work is on the horizon, after we’re through the upcoming focus on reactivity.