-
-
Notifications
You must be signed in to change notification settings - Fork 75
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(api-loader): wait until stable to not block hydration #229
base: main
Are you sure you want to change the base?
fix(api-loader): wait until stable to not block hydration #229
Conversation
Hey @yharaskrik, very interesting contribution. Just have a few questions:
|
Ha! this is why we have code reviews! I forgot to put the load back in, we want the load to be called after the app is stable (or after the timeout) so I can put that back in. The way I have it setup (if I am understanding correctly, if I am wrong please let me know!), is that when No documentation as it currently stands beyond a conversation I had with one of the Angular team members who worked on hydration. (Jessica Janiuk) in the GDE slack, I only ran across it when I was figuring out why hydration was not working for us, loading the Stripe script was fine but as soon as it was loaded then a trusted types call was made which prevented the app from becoming stable and was a large part of why hydration times out. There isn't a TON of documentation on hydration right now unfortunately in terms of technical details/issues etc. I am of course open to other ideas here but what the goal of this was was wait to insert the stripe script until after the app has become stable. |
Now that I look at it though you are right in that this isn't going to work how we want. Let me push up a small change. |
OK updated it a bit, now anytime |
Very nice! Let me make some tests over the weekend and we can merge and release next week 👍 Thanks again |
Hey @yharaskrik, I've been doing some tests and found a few issues:
|
Ah that is good to know, honestly we can return whatever we want from the catchError, the only reason it is there is to catch the timeout so that if the app never becomes stable the script will still end up loading. The docs might never become stable (that is why the timeout is there, to ensure that in that case the script is still loaded). Stability can be affected by numerous things, one of which is setTimeouts/setIntervals and things like that. |
Sorry I haven't had time to come back and make these changes, I fully intend to! |
Hi guys, Also, there could be an alternative solution, loading @stripejs outside of angular zone. Such approach should be more effective, since it will not run unnecessary change detection cycles, and will not wait to load stripe until app become initially stable. |
After some investigation I am not actually sure my solution is going to fix the issue, but loading outside of zone might. If we add the script using JS inside of the run outside of zone will any tasks scheduled by that script that is added also be run outside of zone? |
What are you adding/fixing?
With Hydration in Angular it can only run once the app has become stable, this is not usually a problem but the act of adding the Stripe script to the head delays the app being stable by ~5s (from locally serving SSR), the script itself loads but then it takes some number of seconds to load the trusted types.
This PR updates the lazy api loader service so that it will wait until the app is stable to load the script. It will wait 10 seconds to become stable (same as hydration) and then load the Stripe script anyway.
Will this need documentation changes?
No
Does this introduce a breaking change?
It should not, would depend on if people are expecting the script to be there within a certain timeframe, but if they are they would have race conditions regardless. This change could also be put behind a configuration flag (
waitForStable
or something) as realistically this change is most likely only needed for those using SSR and hydration.Other information