Angular 1.5’s .component() method is very cool, as I wrote about previously. And in general the migration path to Angular 2 recommends that we all stop using controllers in favor of components.

A lot of us are used to using controllers as the route-level objects. Each route has a controller that’s responsible for that specific route, and comes with its own template, etc.

This was comfortable since both ui-router and ngRoute allow us to easily set a controller that handles a route and inject it with dependencies using resolve .

Achieving the same with components isn’t as straightforward, but doable. Note: You might be thinking otherwise, but yes, components should be used for things that aren’t reusable, like handling a specific route. They should actually be used by default for anything that’s not a service in your app.

ngRoute

Say that we’ve got this component:

1 2 3 4 5 myMod . component ( 'inbox' , { templateUrl : 'inbox.component.html' , bindings : { mails : '=' }, controller : function () {...} });

Passing it the mails dependency using resolve is pretty simple:

1 2 3 4 5 6 myMod . config ( function ( $routeProvider ) { $routeProvider . when ( '/inbox' , { template : '<inbox mails="$resolve.mails"></inbox>' , resolve : { mails : function ( Mails ) { return Mails . fetch (); }} }); });

Yes, ngRoute has a handy $resolve property exposed on the scope by default, which saves us some keystrokes and boilerplate in this case.

ui-router

While the upcoming 1.0 release will handle components in a cleaner way, the above solution is available to us since version 0.3:

1 2 3 4 5 6 7 myMod . config ( function ( $stateProvider ) { $stateProvider . state ( 'inbox' , { url : '/inbox' , template : '<inbox mails="$resolve.mails"></inbox>' , resolve : { mails : function ( Mails ) { return Mails . fetch (); }} }); });

Yes, that’s eerily similar to the ngRoute way. Now we get rid ourselves of controllers and get onboard the component train. Choo-choo!