Skip to content

BreakpointObserver doesn't emit immediately #13852

@henry-alakazhang

Description

@henry-alakazhang

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

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions