-
Notifications
You must be signed in to change notification settings - Fork 6.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BreakpointObserver doesn't emit immediately #13852
Comments
You shouldn't wrap your observable with a function. If you use the observable directly it works as expected. https://stackblitz.com/edit/angular-material2-issue-breakpointobserver-vfv5jl For your sample, something like the following seems to work: this.isNotMobile$ = this.isMobile$
.pipe(map(matches => !matches)) <ng-container *ngIf="(isNotMobile$ | async) && (data$ | async) as data">
<!-- use data -->
</ng-container> https://stackblitz.com/edit/angular-material2-issue-breakpointobserver-lyaaca |
The function was just to log and make it clearer what was going on. My stackblitz was admittedly contrived to show everything (and remove the possibility of other things affecting it) Here's a slightly different example, much closer to the actual use case I had an issue with: 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), I've updated the issue with this clearer use case. |
@henry-alakazhang |
I guess this is fixed now as it's synchronous: this.breakpointObserver.observe(Breakpoints.Handset).subscribe(() => console.log(1));
Rx.of(2).subscribe(console.log);
console.log(3); Outputs:
|
This seems to be fixed in master. Closing. |
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Bug, feature request, or proposal:
Bug
What is the expected behavior?
In v6,
BreakpointObserver
immediately emits when subscribed toWhat 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
andstring
.If you swap the contents of
package.json
withpackage.json.2
, this bumps up the version to 7.0.0. The console will printsnull
, thentrue
. The behaviour of| async
has not changed, evidenced by the fact thatstring
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
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), becausebreakpointObserver
doesn't emit immediately andisMobile$ | 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 notThe text was updated successfully, but these errors were encountered: