Make valueChanges a ReplaySubject(1)?

[Airblader]

What's your idea?

We should decide whether the valueChanges observables should be backed by plain Subjects (as-is) or by a ReplaySubject(1).

In the Forms API, it is backed by a Subject, but arguably the initial synchronization from the URL might justify treating it differently in ngqp.

[Airblader]

I really want to say we should do this because otherwise something reactive like

this.items$ = this.paramGroup.valueChanges.pipe(switchMap(…));

combined with the async pipe won't work with the initial sync. I think the benefit of supporting this outweighs the deviation from the Forms API.

[Airblader]

OK, maybe it's not as decisive quite yet. The deviation doesn't bother me as much as the semantics of the word "valueChanges". Perhaps having value$ as a separate observable backed by the ReplaySubject(1) would be more appropriate?

[Airblader]

This can be achieved using

Edit: this contained a mistake, please see the comment further down for the correct version.

It's not super pretty, but let's keep it like this for now.

[Airblader]

See angular/angular#15282

[osahner]

This does not work (at least not with angular 9.1). stackblitz

[steinsag]

Just in case someone else stumbles upon this thread... The correct work-around is:

this.items$ = defer(() => this.paramGroup.valueChanges.pipe(startWith(this.paramGroup.value), switchMap(…)));