refactor: move route configuration to a property of the component constructor

[btford]

WIP: this is something I'm still considering – feedback welcome (yo @PascalPrecht )

I think this would solve several problems, so I'm proposing it as a general solution.

Rationalle

Right now, the set of components that we need to instantiate is dynamically built up on the client. Each component only knows how to map its own level of routing. This is great, because it means we can easily re-mount and reuse routable components.

But in order to open the door for the possibility of server-side rendering, there needs to be a way to statically map a URL to the set of components it needs. This is important that this mapping is static and declarative. This is because some apps might not want to run JS code for router components on the server – like apps which are not written with node.

It's also important so that a parent component can link to a child component. Right now, this is broken.

Other routing systems avoid this problem by consolidating all routing information into a single place before the app bootstraps. This solution is good, but it loses some of the benefits of our earlier approach.

Concrete example of the problem

TODO

Implementation

This is what an app would look like in 1.x:

Before:

function MyController($router) {
  $router.config([ ... ]);
  /* controller init */
}

After:

MyController.$router = [ ... ];
function MyController() {
  /* controller init */
}

With AtScript, you could use annotations to make this a little prettier:

@router([ ... ])
class MyComponent() { ... }

[0x-r4bbit]

@btford could you elaborate on how that would solve the problems?

[btford]

You're fast! I'm still writing this up. I'll ping ya when I'm done

[0x-r4bbit]

Oups. Sorry, didn't want to interrupt.

[diegovilar]

@btford Annotating routing configuration in the component itself might be too coupling... I can see the benefits regarding server-side rendering, but there are situations where that kind of decentralization of configuration could rapidly become a nightmare to maintain. Specially in an application with lots of components, each one defining it's own way of getting to it. It would be like getting rid of indexes and let every entry place themselves wherever they want.

Having said that, there are some settings that are own by the component and thus known by it. Those settings should be defined in the component itself through annotations. Those would include:

• Parameters (the component knows what it needs) - this one might be tricky, since they are part of the path pattern...
• I guess templates too
• Sub-components

The route to get to the top-level component would be configured by the application, though, and the component settings could be overridden at that moment too.

Edit: By the way, the list above seems to be more about component settings than routing settings. Regarding Angular2, the Component annotation seems a better place to put them. But there is no such thing in Angular1...

Edit 2: Regarding parameters, I guess those would just be declared, but how would they be provided in the url would be defined during the route configuration. Something like this, maybe:

In the component annotation:
params: ['publisherName', 'categoryId']

Examples of the router configuration:
url: /books/:publisherName/:categoryId
url: /books/:publisherName/categories/:categoryId
url: /books/:categoryId?publisherName

The purpose of declaring parameters in the component is, well, to make it declarative :) To make it obvious they are needed without having to go through the implementation. The router could also validate the route definition during configuration, checking if such parameters are present in the url. Maybe even allowing for type definition and run-time checking... but then again, maybe this is all out of scope. Need to think more about it.

[timkindberg]

@diegovilar

Specially in an application with lots of components, each one defining it's own way of getting to it.

Components do not define how to get to themselves, that is the job of their parent components. Components define how to fill their own viewports with children components. So the coupling actually makes sense when it's the component defining it's children.

Also, wouldn't your feedback on coupling would be a problem regardless of whether we use an annotation or do the routing in the controller? Perhaps I'm confused on what you are saying.

[timkindberg]

@btford I think this is kind of neat from a separation of concerns perspective. The controller gets to clear out all of that router logic and just focus on being the glue from the business logic (services) to the view (this or $scope).

However, would we lose the runtime aspect of the configuration, like the ability to be really dynamic with our configuration, perhaps even using other injected services to set route configuration properties?

function AppController($router, $thing){
    $router.config([{ path: $thing.path, component: $thing.component }]);
}

I'm not sure how you'd get your hands on $thing with the annotation method, unless you used angular.inject().get().

[btford]

However, would we lose the runtime aspect of the configuration, like the ability to be really dynamic with our configuration, perhaps even using other injected services to set route configuration properties?

Yeah, I want to have both.

This actually landed in v0.5, but it breaks some use cases. I'm still thinking about how best to address this.

I'm traveling at the moment, but expect a lengthy follow up soon.

[btford]

This has since been implemented.