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 }}
Repository navigation
Add wait/no-wait asynchronous policy control to router resolves #24956
[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report
[ ] Performance issue
[x] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question
[ ] Other... Please describe:
Current behavior
Currently, the resolve feature of the Angular Router conflates two similar but discrete functions:
Waiting for a asynchronous dependency to finish loading before performing a navigation.
Allowing a single instantiation for a dependency that is shared by multiple components.
It is often the case that applications want the second of these two functions, but not the first. Many applications choose to keep load-waiting logic in-situ within components, e.g. if they wish to display a skeleton UI, or to run the shared dependency in parallel load with an internal component-specific loading or other instantiation processing.
Expected behavior
The popular 3rd-party UI Router library suffered from the same problem for some time. It was eventually solved by the introduction of a ResolvePolicy setting, which can be specified on a per-resolve basis, and that allows choosing between a WAIT and NOWAIT approach.
Resolvers that are configured with NOWAIT do not block navigation. The result of the resolve is supplied immediately, even if it is a promise/observable. Resolver that are configured as WAIT (the default), do block navigation until any asynchronous load they perform is completed.
I propose adding support for a similar flag to Angular's router.
Minimal reproduction of the problem with instructions
N/A
What is the motivation / use case for changing the behavior?
As explained above. This would make the Angular Router much more useful in real-world applications.
Thank you for submitting your feature request! Looks like during the polling process it didn't collect a sufficient number of votes to move to the next stage.
We want to keep Angular rich and ergonomic and at the same time be mindful about its scope and learning journey. If you think your request could live outside Angular's scope, we'd encourage you to collaborate with the community on publishing it as an open source package.
You can find more details about the feature request process in our documentation.
Activity
angular-robot commentedon Jun 4, 2021
Just a heads up that we kicked off a community voting process for your feature request. There are 20 days until the voting process ends.
Find more details about Angular's feature request process in our documentation.
angular-robot commentedon Jun 24, 2021
Thank you for submitting your feature request! Looks like during the polling process it didn't collect a sufficient number of votes to move to the next stage.
We want to keep Angular rich and ergonomic and at the same time be mindful about its scope and learning journey. If you think your request could live outside Angular's scope, we'd encourage you to collaborate with the community on publishing it as an open source package.
You can find more details about the feature request process in our documentation.
atscott commentedon Jul 23, 2021
Closing in favor of #42953 (added a link to this request from there).
angular-automatic-lock-bot commentedon Aug 23, 2021
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.