Skip to content
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

Removing the problematic share from the zone.js changes #2315

Merged
merged 4 commits into from
Feb 6, 2020

Conversation

jamesdaniels
Copy link
Member

@jamesdaniels jamesdaniels commented Feb 6, 2020

I believe this to be the root cause of #2309, #2314, #2312.

This came up in the review of #2243 but neither my test applications or the test suite caught that it would cause any issues. I merged into 5.x series because I figured fromRef was deep enough in the codebase and dropping a share() wasn't a big deal.

I'm planning to drop this in a patch.

Demonstrating the break fix/here https://stackblitz.com/edit/angular-7kb1uf?file=src%2Fapp%2Fapp.component.ts

@sarunint
Copy link
Contributor

sarunint commented Feb 6, 2020

I'm thinking shareReplay(1) might work here??

@jamesdaniels
Copy link
Member Author

shareReplay(1) could certainly work, but that does have implications (memory) that I'm not sure if I want to take on in a minor.

@jamesdaniels
Copy link
Member Author

Also share() really seems to just be a fix for the server block, perhaps we could shareReplay(1) only in the server env... but I think this needs to be thought out more.

@jamesdaniels
Copy link
Member Author

Thoughts @kamshak? Hate to think I'm missing something here that you already thought out.

@jamesdaniels jamesdaniels merged commit f24df35 into v5 Feb 6, 2020
@jamesdaniels jamesdaniels deleted the problematic_share branch February 6, 2020 05:56
@jamesdaniels
Copy link
Member Author

jamesdaniels commented Feb 6, 2020

Cutting 5.4.2 and 6.0.0-rc.1 now with patches for this. Thanks for you help @sarunint, let's keep the discussion going and make sure we didn't break anything in SSR land.

@ValentinFunk
Copy link
Contributor

@jamesdaniels looks good, sorry didn't run into this issue during testing. It should work fine without the share, it only helped when there were lots of subscriptions to the same (and nested) observables in SSR where sometimes it would cause the zone to block.

Maybe we can find a way to add tests for the issues reported (because of the share) and I'll try to reproduce the Zone issue it was supposed to fix in a test as well so we can safely work on a solution.

jamesdaniels added a commit that referenced this pull request Feb 6, 2020
* Brought a fix in from `5.4.2` ([#2315](#2315))
* Fixed `@angular/fire/analytics` attempting to use `global` ([#2303](#2303))
* Fix the error message on storage ([#2313](#2313))
* Starting on documentation for 6.0
@jamesdaniels
Copy link
Member Author

@kamshak no worries. I didn’t catch it either and you did the community a solid with that massive PR.

I agree some hot/cold/warm/lukewarm 😝 observable tests would be a good guard on future bugs of this sort. No rush though.

If you can repro the lock ups that would probably be most valuable. Would be nice to know at what scale things start acting up.

Also FYI I’m not opposed to a simple shareReplay so long as we’re refcounting.

noproblem23 added a commit to noproblem23/angularfire that referenced this pull request Apr 26, 2023
* Brought a fix in from `5.4.2` ([#2315](angular/angularfire#2315))
* Fixed `@angular/fire/analytics` attempting to use `global` ([#2303](angular/angularfire#2303))
* Fix the error message on storage ([#2313](angular/angularfire#2313))
* Starting on documentation for 6.0
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants