What is the `resolve` equivalent in the new router?

[0x-r4bbit]

I read the source code and also the existing documentation you wrote for the router. Since I try to also sort of compare the old with the new router in the article, I need to explain the resolve $routeProvider config equivalent of the new router.

As far as I understand, instead of having this resolve block, we use canActivate and activate for it. Am I getting this right?

Whereas canActivate decides with the routing happens at all, activate is in charge of doing all the work that is needed to make needed data available in the controller. As you show in the docs, this could be something like:

MyController.prototype.activate = function() {
  return this.bigFiles = this.$http.downloadBigFiles();
};

this.bigFiles is what we usually would request in a resolve block. Please correct me if I'm wrong.

However, I still wonder how this behaves, if we have asynchronous work todo (actually the example looks asynchronous too). In the old router, resolve properties were injected into the controller that is associated to the view.

I understand that we don't need that anymore, as long as we just expose data on this (in the example this.bigFiles), since controller methods can just access it. But what if we have a promise, that needs to resolve first? Is that functionality also (still) supported in the new router?

Hope my question is clear.

[0x-r4bbit]

I've updated the issue title, so it can be properly used as FAQ when searching by labels.

[andrezero]

Hi

It's really cool to have these convention based can methods invoked in the controllers but it's not an alternative for some use cases where having a resolve mechanism defined within the route (and not the controller) is very useful.

For instance, I use resolve for asynchronous authorisation of the requested route+params. These are properties of the router and not the controller and I can assemble two different apps using the same controllers with different authorisation schemes.

Cheers

[niemyjski]

Not to change the subject but I really never liked the use of resolve for anything more than a parameter value that would already be in the route/state params...

So in your case you are resolving big files, and now you are putting logic that knows how to populate that in your router logic... What do you do when big files changes (aka you know it changes from someplace / you get a notification via websocket). Now your only option is to have the get code for big files in two spots or reload the whole view and all children views... Unless, there is an easy way to accomplish reloading your resolved data without destroying the controller and view... I think we should avoid against using resolve when showing people how to load mutable controller data as it could promote a bad practice...

@btford, @PascalPrecht Thoughts??

[kpgarrod]

John Papa's style guide (https://github.com/johnpapa/angular-styleguide#style-y081) recommends the use of route resolves in certain circumstances and provides some good reasons.

[0x-r4bbit]

@niemyjski Thanks for you input. So the bigFiles thing I've mentioned is just an example. It could be anything else. It totally makes sense to have a mechanism like resolve of ngRoute where work needs to be done before the view change takes place. E.g. if you have view/component that only makes sense to be loaded with some specific data you do want to make sure that it's available before the view change happens.

However, I agree with you that it's a rather not so nice way to populate that kind of logic into router logic (as it is currently the case for resolve in ngRoute) but that's why I asked the question here. I've asked the same question via mail and @btford didn't say "yes" to canActivate().

So for me it's still a bit unclear.