Chapter 6
This navigation scheme forms a visual hierarchy that could be depicted as follows:
NAVIGATION BAR
PROJECT INFO
SPRINT INFO
TASKS FOR A GIVEN
SPRINT
NG - VIEW
When switching between tasks views for different sprints within the same project,
we would like to keep the data (and UI) for a given project since it doesn't change.
Unfortunately, the "one route equals one rectangle" principle forces us to reload
the whole dynamic part of the screen, including project-specific partial and its
corresponding data. This in turn means that we need to retrieve the project's model
on each route change, even if it doesn't change from one route to another!
While we can play with the ng-include directive to have proper nesting of visual UI
elements, there is not much we can do about the increased number of data retrievals.
We can only try to make sure that repetitive data retrievals from a back-end are as
fast as possible, or cache subsequent calls to a back-end if suitable.
Routing-specific patterns, tips, and tricks
The earlier sections of this chapter gave us a good overview of the AngularJS APIs,
related to handling navigation in single-page web applications. Here we are going to
see practical examples of using those APIs, and discuss the best related practices.
Handling links
The HTML anchor tag (a) is a primary tool for creating navigation links. AngularJS
has special treatment for those links and the following subsections will guide
through AngularJS specifics.