-
Notifications
You must be signed in to change notification settings - Fork 6.8k
Description
Bug, feature request, or proposal:
Bug
What is the expected behavior?
In v6, BreakpointObserver immediately emits when subscribed to
What is the current behavior?
In v7, BreakpointObserver does not emit immediately.
What are the steps to reproduce?
https://stackblitz.com/edit/angular-material2-issue-breakpointobserver
The initial code is using CDK 6.4.7. The console prints only true and string.
If you swap the contents of package.json with package.json.2, this bumps up the version to 7.0.0. The console will prints null, then true. The behaviour of | async has not changed, evidenced by the fact that string is still printed in the same way.
What is the use-case or motivation for changing an existing behavior?
This causes issues in any code that was not using a strict negation check (eg. !(isMobile$ | async)), as the check becomes truthy temporarily. As an example, this code:
https://stackblitz.com/edit/angular-material2-issue-breakpointobserver-usecase
this.isMobile$ = this.breakpointObserver
.observe(Breakpoints.XSmall)
.pipe(map(obs => obs.matches));
this.isNotMobile$ = this.breakpointObserver
.observe(Breakpoints.XSmall)
.pipe(map(obs => !obs.matches));<div *ngIf="!(isMobile$ | async)">
{{ foo$ | async }}
</div>
<div *ngIf="(isNotMobile$ | async)">
{{ bar$ | async }}
</div>You would expect the two to have the same functionality: nothing is displayed for mobile, and everything is displayed for non-mobile. This is exactly what happens if you move between mobile and non-mobile.
However, if you load it in mobile view (ie. when nothing should show), foo$ is still subscribed to (you can tell by the log), because breakpointObserver doesn't emit immediately and isMobile$ | async === null, which is false-y. This can cause unnecessary network requests to be fired, for example.
Which versions of Angular, Material, OS, TypeScript, browsers are affected?
@angular/cdk 7.0.0
Is there anything else we should know?
This isn't necessarily a bad thing - any problematic behaviour caused can be fixed with strict checks or using startWith, however given it seems to be an undocumented side-effect of #11007 , I'm not sure if it's intended or not