Organizing Navigation
The $route service (and its provider – $routeProvider) allows us to structure
navigation in applications where only one part of the screen (one rectangle) should
be updated in response to a route change. The built-in $route service is largely
sufficient for many applications, but if the described "one route equals one rectangle
change" characteristic is too limiting for your use case, you might consider keeping
an eye on alternative, community-driven solutions. Or if you are brave enough,
consider rolling out your own routing system. You should be well prepared for this
now as this chapter covered the $location service, a lower-level service upon which
the $route service is built.
Toward the end of the chapter we went over a number of patterns, tips, and
solutions for problems that are commonly encountered in larger applications that
use routing. Hopefully, the examples provided in this section of the chapter are
readily applicable to your application as well! We would particularly encourage you
to move route definitions to the corresponding functional modules in order to avoid
maintaining a huge file containing all your route definitions.
Topics dealing with routing and navigation are linked to security considerations.
Indeed, in applications where not all information is public we need to restrict certain
users to a subset of available routes. The next chapter covers patterns for securing
routes as well as many other security-related topics in detail.