8000
You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The reason will be displayed to describe this comment to others. Learn more.
Many thanks @hoebbelsB for taking care of this issue. 🙌
Do we really have to store an application-specific instance of PendingTasks class in a global context?
I'm afraid it's prone to bugs in SSR where multiple apps rendered in parallel can overwrite this single global context property, interfering with other renderings (which ideally should be independent).
In SSR there can exist multiple instances of Angular applications in parallel (each being rendered for a different parallel incoming request) - all executed in the same global NodeJS context.
Therefore, I'm afraid in SSR parallel renderings may interfere with each other, overwriting the NodeJS global shared property let pendingTasks, which can potentially cause bugs.
Again, thank you for taking a look into this issue :)
The reason will be displayed to describe this comment to others. Learn more.
Yea, I can see in the source code of RxAngular that we're now drilling down the NgZone argument deep down through the chain of functions (from RxLet, RxFor, ... directives down to scheduleOnQueue()).
I believe the usecase for the bugfix is valid.
But I can understand your concern: "is the refactoring worth it? (e.g. drilling down an instance of PendingTasks"
The reason will be displayed to describe this comment to others. Learn more.
Hi @hoebbelsB ,
I'm not rushing for implementation, I'm aware you have plenty of responsibilities.
I could possibly go ahead and contribute a PR proposal, if only having green light from you. But I'm also not pushing for it, just asking.
So let me just ask for your architectural opinion:
Do you think it would be OK to drill down the PendingTasks object of Angular, same like we drill down the NgZone object - from the RxFor instance down through all nested function invocations down to the scheduleOnQueue() function?
I could take the human effort implement it. But I feel responsible for the long term business and architectural pros&cons of it, so I'm listing pros&cons below (feel free to add something if I missed anything):
pros: it unblocks us to fix the bug of RxFor (and other directives) causing the destroy of the DOM (and sometimes degrading CLS metric) despite Angular native "non-destructive-hydration" being enabled
cons: changing many places in the codebase just for one usecase - "pollutting" many the functions with the new (optional) param PendingTasks
Breaking changes in the TS API can be avoided thanks to:
some functions already being private API, so the new param can be required in TS types
public API functions can get the new param as an optional one
I have problem to find alternative approaches, due to my limited knowledge about the RxAngular/Template architecture. Feel free to share what alternative approaches and their pros&cons can you see. Or maybe you're fine with the approach mentioned above.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.
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.
Many thanks @hoebbelsB for taking care of this issue. 🙌
Do we really have to store an application-specific instance of
PendingTasks
class in a global context?I'm afraid it's prone to bugs in SSR where multiple apps rendered in parallel can overwrite this single global context property, interfering with other renderings (which ideally should be independent).
More details:
PendingTasks
is provided in the root injector, so it's scoped to a single instance of an application.let pendingTasks
, which can potentially cause bugs.Again, thank you for taking a look into this issue :)
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.
thanks for pointing that out. It might require a bigger refactoring from our end in that case. Let me think about it
Uh oh!
There was an error while loading. Please reload this page.
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.
Yea, I can see in the source code of RxAngular that we're now drilling down the
NgZone
argument deep down through the chain of functions (from RxLet, RxFor, ... directives down toscheduleOnQueue()
).I believe the usecase for the bugfix is valid.
But I can understand your concern: "is the refactoring worth it? (e.g. drilling down an instance of
PendingTasks
"Uh oh!
There was an error while loading. Please reload this page.
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.
Hi @hoebbelsB ,
I'm not rushing for implementation, I'm aware you have plenty of responsibilities.
I could possibly go ahead and contribute a PR proposal, if only having green light from you. But I'm also not pushing for it, just asking.
So let me just ask for your architectural opinion:
Do you think it would be OK to drill down the
PendingTasks
object of Angular, same like we drill down theNgZone
object - from theRxFor
instance down through all nested function invocations down to thescheduleOnQueue()
function?I could take the human effort implement it. But I feel responsible for the long term business and architectural pros&cons of it, so I'm listing pros&cons below (feel free to add something if I missed anything):
RxFor
(and other directives) causing the destroy of the DOM (and sometimes degrading CLS metric) despite Angular native "non-destructive-hydration" being enabledPendingTasks
Breaking changes in the TS API can be avoided thanks to:
I have problem to find alternative approaches, due to my limited knowledge about the RxAngular/Template architecture. Feel free to share what alternative approaches and their pros&cons can you see. Or maybe you're fine with the approach mentioned above.
Many thanks!