Run multiple resolvers concurrently in router.

[Iverson]

I'm submitting a ... (check one with "x")

[ ] bug report => search github for a similar issue or PR before submitting
[x] feature request
[ ] support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Current behavior
I set multiple resolvers in my route:

export const routes: Routes = [
  {
    path: '',
    children: appRoutes,
    canActivate: [AuthGuard],
    resolve: {
      capabilities: CapabilitiesResolver,
      userInfo: OrganizationUserResolver,
      organizations: OrganizationResolver
    }
  }
]

each of them implements Resolve interface and return Observable:

@Injectable()
export class CapabilitiesResolver implements Resolve<Endpoint[]> {
  constructor(private capabilitiesService: CapabilitiesService) {}

  resolve(route: ActivatedRouteSnapshot, state: RouterStateSnapshot): Observable<Endpoint[]> {
    return this.capabilitiesService.fetch()
  }
}

as result all http requests run sequentially and this is not useful behavior for UX. But if resolvers return Promise instead of Observable:

resolve(route: ActivatedRouteSnapshot, state: RouterStateSnapshot): Promise<Endpoint[]> {
    return this.capabilitiesService.fetch().toPromise()
  }

then all requests will be ran concurrently, very implicit behavior...

Expected behavior
No matter what resolve() method return (Observable or Promise) all async operations should be ran concurrently.

What is the motivation / use case for changing the behavior?
For users: Improve UX when router pre-fetch data.
For developers: More explicit router API.

Please tell us about your environment:
@angular/cli: 1.0.0-beta.30
node: 6.2.2
os: darwin x64
@angular/common: 2.4.1
@angular/compiler: 2.4.1
@angular/core: 2.4.1
@angular/forms: 2.4.1
@angular/http: 2.4.1
@angular/platform-browser: 2.4.1
@angular/platform-browser-dynamic: 2.4.1
@angular/router: 3.4.1
@angular/compiler-cli: 2.4.1

• Angular version: 2.4.1

• Browser: all

• Language: TypeScript 2.0.3

[saedwards]

This looks interesting. I've currently got the problem whereby at a single route I need to wait for data from the result of one resolvers service call to complete before calling another service with the previous resolved data. How would I be able to do this with the above changes?

[bumbapartha]

We could have a chain of resolver dependency to solve this problem. May be the the following approach can be used.

{
    path : '',
    component : '',
    resolve : {
        data1 : {
            resolver: Data1Resolver
            resolve : {
                subdata1 : SubData1Resolver
            }
        },
        data2 : Data2Resolver
    }
}

Note : We can get the data loaded by Data1Resolver inside the resolve method of SubData1Resolver. So that synchronous resolver can be called and data can be shared.

[saedwards]

That looks good. Just to clarify - You'd get the choice of both, data1 & data2 resolve concurrently. And subdata1 values resolve sequentially after data1 values are resolved. Is this not available already? It sounds like it would be a solution to a very common problem, I haven't found anything on the Angular site.

[bhaidar]

Is this feature available now in Angular 4? If I have multiple resolvers, would they run concurrently?

[brandon7810]

Hi I would like to know the state of this issue since I do not want to run my resolvers concurrently. I would need them to be executed sequentially. @hibumbapartha is your code working?

[MickL]

Actually i need the opposite: One guard (resolve or canActivate) should WAIT for the previous before it executes. I have to prevent concurrent execution.

[felipe-norato]

@MickL I need the same thing!

[MickL]

I opened a issue here: #21702

Feel free to give it a thumbs up

[stevedeighton]

So to clarify, there's no in built way to resolve multiple one after each other, like how it used to work?

'cause if so this makes me weep a little!

[angular-automatic-lock-bot]

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.}