I'm submitting a...

[ ] 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:

1. Waiting for a asynchronous dependency to finish loading before performing a navigation.
2. 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.

Environment

Angular version: 6.0.9


Browser: N/A