docs(guide/Component Router): describe your change... #14237
Conversation
From what I can tell, the only way of "resolving" for a component route is in the component's definition object and the method is $canActivate, not $routerCanActivate. Adding a $routerCanActivate alternative would be helpful as a method that can be called on the constructor. I did find a helpful min-safe pattern that might be worth documenting. This is the ability to inject into the CDO's $canActivate method by putting to-be-injected module strings AFTER the default parameters ($nextInstruction and $prevInstruction), followed by the callback with the injected modules as the 3rd - xx arguments. This way I can reference a service to check authentication status (for example), returning a promise that will resolve to true or false and thereby either permit the route to proceed or kill it. However, the best feature would be to add some way to reference a routeProvider, as with ngRoute, for global $canActivate patterns. A pattern I had successfully used with ngRoute was to extend the "when" method to do my authentication check and abort any route that had a configuration setting like "requiresAuth." To be able to do the same with component-based routes would be helpful, but I haven't figured out how. Thanks.
|
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please visit https://cla.developers.google.com/ to sign. Once you've signed, please reply here (e.g.
|
1 similar comment
|
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please visit https://cla.developers.google.com/ to sign. Once you've signed, please reply here (e.g.
|
|
I have signed the CLA. Thanks, Josh Schneider On Mon, Mar 14, 2016 at 2:28 PM, googlebot [email protected] wrote:
|
|
CLAs look good, thanks! |
1 similar comment
|
CLAs look good, thanks! |
|
While this change is accurate, right now. I actually want to change the hook's name to be |
|
I kind of thought that might be the case. As an option, maybe it should be made very clear on the new documentation (like right at the top) what the exact status of ngcomponentrouter is. I'm sure I'm not alone in trying to setup a new 1.5.x project and take advantage of components and the component router, but the router itself seems to be an afterthought to 2.x development. I'm sure the team is ridiculously busy, so if you have any recommendations for other mods to the 1.5.x component router docs, I will put in a different PR. Thanks. |
|
OK, let's merge this since it is the status quo. There will have to be a breaking change announcement with a rename of the hook anyway |
The hook will most likely be named back to `$routerCanActivate` in the future, but for now this change is accurate. Closes #14237
|
Thanks, Pete. On Wed, Mar 16, 2016 at 9:50 AM, Pete Bacon Darwin <[email protected]
|
What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Docs update
What is the current behavior? (You can also link to an open issue here)
Method $routerCanActivate lifecycle hook does not appear to exist for components in 1.x
What is the new behavior (if this is a feature change)?
The $canActivate hook on the CDO appears to be the only way to control route resolution for components in 1.x
Does this PR introduce a breaking change?
No
Please check if the PR fulfills these requirements
Other information:
NOTES:
From what I can tell, the only way of "resolving" for a component route is in the component's definition object and the method is $canActivate, not $routerCanActivate. Adding a $routerCanActivate alternative would be helpful as a method that can be called on the constructor.
I did find a helpful min-safe pattern that might be worth documenting. This is the ability to inject into the CDO's $canActivate method by putting to-be-injected module strings AFTER the default parameters ($nextInstruction and $prevInstruction), followed by the callback with the injected modules as the 3rd - xx arguments. This way I can reference a service to check authentication status (for example), returning a promise that will resolve to true or false and thereby either permit the route to proceed or kill it.
However, the best feature would be to add some way to reference a routeProvider, as with ngRoute, for global $canActivate patterns. A pattern I had successfully used with ngRoute was to extend the "when" method to do my authentication check and abort any route that had a configuration setting like "requiresAuth." To be able to do the same with component-based routes would be helpful, but I haven't figured out how. Thanks.