{"action":"created","issue":{"url":"https://api.github.com/repos/angular/angular/issues/6040","labels_url":"https://api.github.com/repos/angular/angular/issues/6040/labels{/name}","comments_url":"https://api.github.com/repos/angular/angular/issues/6040/comments","events_url":"https://api.github.com/repos/angular/angular/issues/6040/events","html_url":"https://github.com/angular/angular/issues/6040","id":123175479,"number":6040,"title":"Rename @RouteConfig to @Routes","user":{"login":"alexpods","id":4254276,"avatar_url":"https://avatars.githubusercontent.com/u/4254276?v=3","gravatar_id":"","url":"https://api.github.com/users/alexpods","html_url":"https://github.com/alexpods","followers_url":"https://api.github.com/users/alexpods/followers","following_url":"https://api.github.com/users/alexpods/following{/other_user}","gists_url":"https://api.github.com/users/alexpods/gists{/gist_id}","starred_url":"https://api.github.com/users/alexpods/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/alexpods/subscriptions","organizations_url":"https://api.github.com/users/alexpods/orgs","repos_url":"https://api.github.com/users/alexpods/repos","events_url":"https://api.github.com/users/alexpods/events{/privacy}","received_events_url":"https://api.github.com/users/alexpods/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":16,"created_at":"2015-12-20T18:16:38Z","updated_at":"2015-12-22T15:43:47Z","closed_at":null,"body":"Why `@RouteConfig` is bad:\r\n- two words\r\n- `Config` suffix, that makes no sense. Similarly we could have `@ViewConfig` instead of `@View` (and it was like so [a long time ago in a galaxy far far away...](https://github.com/angular/angular/blob/97f6ceb27b918bfae99dcc46ebdda5a1d8c55f47/modules/core/src/annotations/template_config.js#L3))\r\n- actually we use it to specify \"a list of routes\", not \"a route config\"\r\n\r\nProposed name: `@Routes`\r\n- one word\r\n- have a correct meaning (\"a list of routes\")\r\n\r\nExample:\r\n\r\n```ts\r\n@Component({\r\n    selector: 'some-component',\r\n    template: '<router-outlet></router-outlet>'\r\n})\r\n@Routes([\r\n    {path: '/', redirectTo: ['/Home']},\r\n    {path: '/home',  as: 'Home',  component: Home},\r\n    {path: '/stats', as: 'Stats', component: Stats},\r\n])\r\nclass SomeComponent {}\r\n```\r\n\r\n@btford @mhevery @IgorMinar \r\n\r\n**PS** Of course `@RouteConfig` should be deprecated, not removed."},"comment":{"url":"https://api.github.com/repos/angular/angular/issues/comments/166651035","html_url":"https://github.com/angular/angular/issues/6040#issuecomment-166651035","issue_url":"https://api.github.com/repos/angular/angular/issues/6040","id":166651035,"user":{"login":"thelgevold","id":349548,"avatar_url":"https://avatars.githubusercontent.com/u/349548?v=3","gravatar_id":"","url":"https://api.github.com/users/thelgevold","html_url":"https://github.com/thelgevold","followers_url":"https://api.github.com/users/thelgevold/followers","following_url":"https://api.github.com/users/thelgevold/following{/other_user}","gists_url":"https://api.github.com/users/thelgevold/gists{/gist_id}","starred_url":"https://api.github.com/users/thelgevold/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/thelgevold/subscriptions","organizations_url":"https://api.github.com/users/thelgevold/orgs","repos_url":"https://api.github.com/users/thelgevold/repos","events_url":"https://api.github.com/users/thelgevold/events{/privacy}","received_events_url":"https://api.github.com/users/thelgevold/received_events","type":"User","site_admin":false},"created_at":"2015-12-22T15:43:47Z","updated_at":"2015-12-22T15:43:47Z","body":"I think with this we run the risk of putting to much logic/responsibility on the router and risk creating applications with unnecessary dependencies on Angular 2 (and its router). I get how it's nice to tie a general authentication check to the router, but I think that should be done as a general request validation mechanism - not at the component or individual route level. \r\n\r\nSecondly, I don't like the idea of running specific canActivate logic in each component to govern the routes/links. In my opinion this is better suited for custom logic running outside the router. This will ensure that that logic is decoupled and free of router dependencies. Year from now, porting a solution that relies heavily on a very specific router implementation does not seem desirable. Unit testing seems more challenging as well."}}