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
The behavior NavigationManager exhibits is different in SSR rendering than it is on other interactive modes. In particular, SSR relies on throwing an exception that gets captured by the framework to convert the error into a redirect.
This behavior leads to a poor user experience where users debugging their apps typically see the debugger break when this exception is thrown and incorrectly believe that there is an error/bug on the framework.
In addition to this, code that exists after a call to NavigateTo will continue to execute on interactive render modes but will abruptly stop in SSR scenarios.
The solution for this involves a breaking change, but the number of issues that the current behavior produces justifies such change. We should stop throwing an exception during SSR and instead signal the underlying renderer that a redirection has been requested. We should continue to execute the current ongoing synchronous render batch until completion and, once it finishes, we should dispose the existing renderer and trigger the redirect. This will align the behavior with what happens in other platforms, but we should also have a suite of tests that capture these behaviors across render modes to ensure a consistent experience.
For backcompat reasons we will include an AppContext switch that will continue to throw the exception in case someone needs it.
The text was updated successfully, but these errors were encountered:
The behavior NavigationManager exhibits is different in SSR rendering than it is on other interactive modes. In particular, SSR relies on throwing an exception that gets captured by the framework to convert the error into a redirect.
This behavior leads to a poor user experience where users debugging their apps typically see the debugger break when this exception is thrown and incorrectly believe that there is an error/bug on the framework.
In addition to this, code that exists after a call to
NavigateTo
will continue to execute on interactive render modes but will abruptly stop in SSR scenarios.The solution for this involves a breaking change, but the number of issues that the current behavior produces justifies such change. We should stop throwing an exception during SSR and instead signal the underlying renderer that a redirection has been requested. We should continue to execute the current ongoing synchronous render batch until completion and, once it finishes, we should dispose the existing renderer and trigger the redirect. This will align the behavior with what happens in other platforms, but we should also have a suite of tests that capture these behaviors across render modes to ensure a consistent experience.
For backcompat reasons we will include an AppContext switch that will continue to throw the exception in case someone needs it.
The text was updated successfully, but these errors were encountered: