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
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.
Say that we’ve got this component:
1 2 3 4 5
Passing it the
mails dependency using
resolve is pretty simple:
1 2 3 4 5 6
Yes, ngRoute has a handy
$resolve property exposed on the scope by default, which saves us some keystrokes and boilerplate in this case.
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
Yes, that’s eerily similar to the ngRoute way. Now we get rid ourselves of controllers and get onboard the component train. Choo-choo!
“Maintaining AngularJS feels like Cobol 🤷…”
You want to do AngularJS the right way.
Yet every blog post you see makes it look like your codebase is obsolete. Components? Lifecycle hooks? Controllers are dead?
It would be great to work on a modern codebase again, but who has weeks for a rewrite?
Well, you can get your app back in shape, without pushing back all your deadlines! Imagine, upgrading smoothly along your regular tasks, no longer deep in legacy.
Subscribe and get my free email course with steps for upgrading your AngularJS app to the latest 1.6 safely and without a rewrite.