Organizing Navigation
Providing further details on how to configure different servers is beyond the scope of
this book, but there are some general rules that apply to all servers. Firstly, there are
roughly three types of URLs that a typical web server needs to handle:
- URLs pointing to static resources (images, CSS files, AngularJS partials, and
so on) - URLs for back-end data retrieval or modifications requests (for instance, a
RESTful API) - URLs that represent features of the application in HTML5 mode, where
the server must respond with the application's landing page (typically a
bookmarked URL used, or a URL typed in in a browser's address bar)
Since it is cumbersome to enumerate all the URLs that can hit a web server due to
the HTML5 mode links, it is probably the best to use a well-known prefix for both
static resources and URLs used to manipulate data. This is a strategy employed by
the sample SCRUM application where all the static resources are served from the
URLs with the /static prefix, while the ones prefixed with the /databases prefix
are reserved for data manipulation on a back-end. Most of the remaining URLs are
redirected to the starting point of the SCRUM application (index.html).
Handcrafting navigation using the $location service
Now that we are familiar with the $location service API and its configuration,
we can put the freshly acquired knowledge into practice by building a very simple
navigation scheme using the ng-include directive and the $location service.
Even the simplest navigation scheme in a single-page web application should offer
some fundamental facilities to make developers life easier. As a bare minimum we
should be able to perform the following activities:
- Define routes in a consistent, easy to maintain manner
- Update the application's state in response to URL changes
- Change the URL in response to the users navigating around the application
(clicking on a link, using back and forward buttons in a browser, and so on)
In the rest of this book, the term routing is used to denote a facility
that helps synchronize the application's state (both screens and
corresponding model) in response to URL changes. A single route is
a collection of metadata used to transition an application to a state
matching a given URL.