canActivate not called from prototype

[mafredri]

canActivate does not follow the same pattern as activate, deactivate and canDeactivate. Tested on latest master (077bfb6172074662ed4ab5fad6d624790fb4f3e2, built with gulp).

Fails:

AuthController.prototype.canActivate = function canActivate() {
  console.log('Auth canActivate');
};

Works:

AuthController.canActivate = function canActivate() {
  console.log('Auth canActivate');
};

[btford]

This is intended behavior.

You don't know whether or not to instantiate a component until after you figure out if you can navigate to it.

[mafredri]

Ok, I think I understand now, but just to confirm that there is no miscommunication: This behavior is different between v0.5.3 and master, is that how it's supposed to be? Documentation also states it should be as in v0.5.3, not as it is on master.

I can understand the logic for having canActivate as static, but it brings some limitations:

• You can no longer write function AuthController() { this.canActivate = function() {}; }
• You cannot use this inside the canActivate function, and must therefore inject dependencies into canActivate.

Isn't the whole reason for having a activate lifecycle hook there to perform tasks when the controller in fact gets activated? In my opinion it should always be ok to instantiate a component (assuming this refers to the controller), and then perform the canActivate check.

[btford]

@mafredri – this won't fly for Angular 1. It would mean creating $scopes and registering watches if the constructor asks for them, or it would mean that you cannot inject $scope into controller constructors (which was previously the case).

[mafredri]

That makes sense, thanks for the clarifications! Was just surprised to discover the API change, glad to know there are valid reasons behind it.