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 Nov 22, 2024. It is now read-only.
Repository navigation
This repository was archived by the owner on Nov 22, 2024. It is now read-only.
Server crashes from evaluating functions executed after setTimeout #267
Currently Universal will crash when parsing an unsupported function executed after setTimeOut, even though the function is not executed until after the page is fully loaded...for example...
@gdi2290 yes, I understand that... the issue that was brought up in slack chat is more so that the server would not be executing that function anyway since it won't execute the setTimeout block until after the page has fully downloaded, therefore the setTimeout block should be ignored or better handled.
@gdi2290 this is interesting because some people want the body of setTimeout to be executed on the server. I think that we should likely make a hard, clear stance on async on the server. What do you think about making sure we wait on the server for both http and some new modules we create to wrap setTimeout (i.e. universalTimeout or whatever), but then all other setTimeouts are monkey patched on the server to do nothing.
Alternatively we can just tell people not to use setTimeout, but that may just lead to inevitable issues.
@qdouble we’re tracking setTimeout, setInterval (although no one should use this for SSR), and setImmediate now in zone.js with angular2-universal-polyfills 0.3.1 and our new way of checking when the app is stable via checkStable
Activity
PatrickJS commentedon Feb 11, 2016
'focus'was not implemented for the server version of the DOM adaptorqdouble commentedon Feb 11, 2016
@gdi2290 yes, I understand that... the issue that was brought up in slack chat is more so that the server would not be executing that function anyway since it won't execute the setTimeout block until after the page has fully downloaded, therefore the setTimeout block should be ignored or better handled.
jeffwhelpley commentedon Feb 23, 2016
@gdi2290 this is interesting because some people want the body of setTimeout to be executed on the server. I think that we should likely make a hard, clear stance on async on the server. What do you think about making sure we wait on the server for both http and some new modules we create to wrap setTimeout (i.e. universalTimeout or whatever), but then all other setTimeouts are monkey patched on the server to do nothing.
Alternatively we can just tell people not to use setTimeout, but that may just lead to inevitable issues.
PatrickJS commentedon Apr 3, 2016
@qdouble we’re tracking
setTimeout,setInterval(although no one should use this for SSR), andsetImmediatenow in zone.js with angular2-universal-polyfills0.3.1and our new way of checking when the app is stable viacheckStableangular-automatic-lock-bot commentedon Sep 4, 2019
This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
This action has been performed automatically by a bot.