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
{{ message }}
This repository was archived by the owner on Mar 20, 2024. It is now read-only.
Even if application root exists when Preboot starts listening for events the server node may not be available in full yet. Since Preboots searches for nodes matching desired selectors inside of the existsing serverNode, it may skip some of them if the server node hasn't loaded fully. This is especially common if the internet connection is slow.
Preboot waits for body in a tight loop, checking every 10 milliseconds. This starves the browser but may also be clamped by it to a larger delay (around 1 second); that's what happens in modern browsers if the tab where the page loads is inactive, e.g. if you open a link in a new tab in Chrome or Firefox. This means Preboot may start listening for events after Angular reports the app is stable and the PrebootComplete event fires. This then leaves the server node active, never transferring to the client one which makes for a broken site.
If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem by creating a github repo.
I don't have a quick test case at hand; however, the description from the previous point shows how to reproduce it.
What is the expected behavior?
Preboot shouldn't suffer from race conditions.
What is the motivation / use case for changing the behavior?
The current behavior is buggy as described above.
Please tell us about your environment:
Browser: all
Language: all
OS: all
Platform: all
Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)
Since we want to attach event listeners as soon as possible when the server node starts being available (so that it can be shallow-cloned) we cannot wait for it to be available in full. Therefore, we need to use delegated event handlers on document instead of on specific nodes.
As we support multiple app roots, to not duplicate large inline preboot code, we'll split getInlinePrebootCode into two parts: function definitions to be put in <head> and the invocation separate for each app root put just after the app root opening tag. We'll maintain getInlinePrebootCode for backwards compatibility but we'll no longer use it internally.
To maintain children offset numbers (otherwise selectors won't match between the client & the server) we'll remove the in-app-root script immediately when it starts executing; this won't stop execution. document.currentScript is a good way to find the currently running script but it doesn't work in IE. We'll need to apply a fallback behavior for IE, perhaps by tagging each script with a unique attribute value and injecting this value as a variable into the script.
We'll remove waitUntilReady as there's no reliable way to wait; we'll invoke the init code immediately instead.
We'll attach the overlay used for freeing the UI to document.documentElement instead of document.body so that we don't have to wait for body.
Note: for support questions, please use the Universal Slack Channcel or https://gitter.im/angular/universal
A bug.
Currently Preboot suffers from various race conditions:
document.bodyto be available and then applies its logic. However, the application root may not be available at this point - see issue add condition to check that the application root is available in the DOM before prebooting #72.serverNode, it may skip some of them if the server node hasn't loaded fully. This is especially common if the internet connection is slow.bodyin a tight loop, checking every 10 milliseconds. This starves the browser but may also be clamped by it to a larger delay (around 1 second); that's what happens in modern browsers if the tab where the page loads is inactive, e.g. if you open a link in a new tab in Chrome or Firefox. This means Preboot may start listening for events after Angular reports the app is stable and thePrebootCompleteevent fires. This then leaves the server node active, never transferring to the client one which makes for a broken site.I don't have a quick test case at hand; however, the description from the previous point shows how to reproduce it.
Preboot shouldn't suffer from race conditions.
The current behavior is buggy as described above.
documentinstead of on specific nodes.getInlinePrebootCodeinto two parts: function definitions to be put in<head>and the invocation separate for each app root put just after the app root opening tag. We'll maintaingetInlinePrebootCodefor backwards compatibility but we'll no longer use it internally.document.currentScriptis a good way to find the currently running script but it doesn't work in IE. We'll need to apply a fallback behavior for IE, perhaps by tagging each script with a unique attribute value and injecting this value as a variable into the script.waitUntilReadyas there's no reliable way to wait; we'll invoke the init code immediately instead.document.documentElementinstead ofdocument.bodyso that we don't have to wait forbody.