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
fix(core): Multiple subscribers to ApplicationRef.isStable should all… #53541
Conversation
… see values The behavior of `ApplicationRef.isStable` changed in 16.1 due to angular@28c68f7. This change added a `share` to the `isStable` observable, which prevents additional subscribers from getting a value until a new one emits. One solution to the problem would be `shareReplay(1)`. However, that would increase the bundle size since we do not use `shareReplay` elsewhere. Instead, we don't even really need to share the observable. The `Observable` available in `ApplicationRef.isStable` before the above commit was the zone stable observable, without a `share`. The new behavior adds only an additional observable to the stream, `hasPendingTasks` (a `BehaviorSubject`). The observables in this stream are not expensive to subscribe to. The only one with side effects is the `isStable` (because it subscribes to onStable), but that one already has the `share` operator on it. Omitting the `share` in `ApplicationRef` also means that applications on `zoneless` will not have to pay the cost of the operator when we make zones optional because the zone stable observable is the only place we use it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@atscott thanks for the fix! 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
Initially the share
was there to have a single source of truth when having multiple subscriptions to isStable
.
This PR was merged into the repository by commit 629343f. |
… see values (#53541) The behavior of `ApplicationRef.isStable` changed in 16.1 due to 28c68f7. This change added a `share` to the `isStable` observable, which prevents additional subscribers from getting a value until a new one emits. One solution to the problem would be `shareReplay(1)`. However, that would increase the bundle size since we do not use `shareReplay` elsewhere. Instead, we don't even really need to share the observable. The `Observable` available in `ApplicationRef.isStable` before the above commit was the zone stable observable, without a `share`. The new behavior adds only an additional observable to the stream, `hasPendingTasks` (a `BehaviorSubject`). The observables in this stream are not expensive to subscribe to. The only one with side effects is the `isStable` (because it subscribes to onStable), but that one already has the `share` operator on it. Omitting the `share` in `ApplicationRef` also means that applications on `zoneless` will not have to pay the cost of the operator when we make zones optional because the zone stable observable is the only place we use it. PR Close #53541
… see values (angular#53541) The behavior of `ApplicationRef.isStable` changed in 16.1 due to angular@28c68f7. This change added a `share` to the `isStable` observable, which prevents additional subscribers from getting a value until a new one emits. One solution to the problem would be `shareReplay(1)`. However, that would increase the bundle size since we do not use `shareReplay` elsewhere. Instead, we don't even really need to share the observable. The `Observable` available in `ApplicationRef.isStable` before the above commit was the zone stable observable, without a `share`. The new behavior adds only an additional observable to the stream, `hasPendingTasks` (a `BehaviorSubject`). The observables in this stream are not expensive to subscribe to. The only one with side effects is the `isStable` (because it subscribes to onStable), but that one already has the `share` operator on it. Omitting the `share` in `ApplicationRef` also means that applications on `zoneless` will not have to pay the cost of the operator when we make zones optional because the zone stable observable is the only place we use it. PR Close angular#53541
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. |
… see values (angular#53541) The behavior of `ApplicationRef.isStable` changed in 16.1 due to angular@28c68f7. This change added a `share` to the `isStable` observable, which prevents additional subscribers from getting a value until a new one emits. One solution to the problem would be `shareReplay(1)`. However, that would increase the bundle size since we do not use `shareReplay` elsewhere. Instead, we don't even really need to share the observable. The `Observable` available in `ApplicationRef.isStable` before the above commit was the zone stable observable, without a `share`. The new behavior adds only an additional observable to the stream, `hasPendingTasks` (a `BehaviorSubject`). The observables in this stream are not expensive to subscribe to. The only one with side effects is the `isStable` (because it subscribes to onStable), but that one already has the `share` operator on it. Omitting the `share` in `ApplicationRef` also means that applications on `zoneless` will not have to pay the cost of the operator when we make zones optional because the zone stable observable is the only place we use it. PR Close angular#53541
… see values (angular#53541) The behavior of `ApplicationRef.isStable` changed in 16.1 due to angular@28c68f7. This change added a `share` to the `isStable` observable, which prevents additional subscribers from getting a value until a new one emits. One solution to the problem would be `shareReplay(1)`. However, that would increase the bundle size since we do not use `shareReplay` elsewhere. Instead, we don't even really need to share the observable. The `Observable` available in `ApplicationRef.isStable` before the above commit was the zone stable observable, without a `share`. The new behavior adds only an additional observable to the stream, `hasPendingTasks` (a `BehaviorSubject`). The observables in this stream are not expensive to subscribe to. The only one with side effects is the `isStable` (because it subscribes to onStable), but that one already has the `share` operator on it. Omitting the `share` in `ApplicationRef` also means that applications on `zoneless` will not have to pay the cost of the operator when we make zones optional because the zone stable observable is the only place we use it. PR Close angular#53541
… see values (angular#53541) The behavior of `ApplicationRef.isStable` changed in 16.1 due to angular@28c68f7. This change added a `share` to the `isStable` observable, which prevents additional subscribers from getting a value until a new one emits. One solution to the problem would be `shareReplay(1)`. However, that would increase the bundle size since we do not use `shareReplay` elsewhere. Instead, we don't even really need to share the observable. The `Observable` available in `ApplicationRef.isStable` before the above commit was the zone stable observable, without a `share`. The new behavior adds only an additional observable to the stream, `hasPendingTasks` (a `BehaviorSubject`). The observables in this stream are not expensive to subscribe to. The only one with side effects is the `isStable` (because it subscribes to onStable), but that one already has the `share` operator on it. Omitting the `share` in `ApplicationRef` also means that applications on `zoneless` will not have to pay the cost of the operator when we make zones optional because the zone stable observable is the only place we use it. PR Close angular#53541
… see values (angular#53541) The behavior of `ApplicationRef.isStable` changed in 16.1 due to angular@28c68f7. This change added a `share` to the `isStable` observable, which prevents additional subscribers from getting a value until a new one emits. One solution to the problem would be `shareReplay(1)`. However, that would increase the bundle size since we do not use `shareReplay` elsewhere. Instead, we don't even really need to share the observable. The `Observable` available in `ApplicationRef.isStable` before the above commit was the zone stable observable, without a `share`. The new behavior adds only an additional observable to the stream, `hasPendingTasks` (a `BehaviorSubject`). The observables in this stream are not expensive to subscribe to. The only one with side effects is the `isStable` (because it subscribes to onStable), but that one already has the `share` operator on it. Omitting the `share` in `ApplicationRef` also means that applications on `zoneless` will not have to pay the cost of the operator when we make zones optional because the zone stable observable is the only place we use it. PR Close angular#53541
… see values
The behavior of
ApplicationRef.isStable
changed in 16.1 due to 28c68f7. This change added ashare
to theisStable
observable, which prevents additional subscribers from getting a value until a new one emits. One solution to the problem would beshareReplay(1)
. However, that would increase the bundle size since we do not useshareReplay
elsewhere. Instead, we don't even really need to share the observable.The
Observable
available inApplicationRef.isStable
before the above commit was the zone stable observable, without ashare
. The new behavior adds only an additional observable to the stream,hasPendingTasks
(aBehaviorSubject
). The observables in this stream are not expensive to subscribe to. The only one with side effects is theisStable
(because it subscirbes to onStable), but that one already has theshare
operator on it. Omitting theshare
inApplicationRef
also means that applications onzoneless
will not have to pay the cost of the operator when we make zones optional because the zone stable observable is the only place we use it.