Client-Side Routing

Traditional websites navigate by making a new HTTP request to the server for each page. The browser receives a new HTML document, loads it, and the page re-renders from scratch. This works, but it is slow and breaks the feeling of a seamless application.

Single-page applications (SPAs) take a different approach: the browser downloads one HTML file once, and JavaScript manages navigation from there. When the user clicks a link, the JavaScript router:

1. Intercepts the navigation
2. Updates the URL using the browser’s History API
3. Renders a different component without requesting a new HTML document

The result is instant navigation with no page flicker.

The browser History API

The History API is a browser feature that lets JavaScript manipulate the browser’s navigation stack without triggering a server request:

// Push a new URL to history (no page reload)
history.pushState(null, '', '/about');

// Replace the current entry
history.replaceState(null, '', '/movies/1');

Angular’s router wraps this API. When you navigate in Angular, it calls pushState under the hood, which changes the address bar URL without reloading the page. Then Angular re-renders the appropriate component.

Why client-side routing matters

Without client-side routing, a user clicking from /movies to /movies/123 would wait for a server round-trip. With client-side routing:

• Navigation is instant (no network request)
• JavaScript state is preserved (loaded data, scroll position, animation state)
• The URL still reflects the current page — the browser’s back button works correctly

In CinemaVault, clicking a movie card navigates to /movies/:id and renders the MovieDetail component instantly — no server involved.

How Angular’s router works

The Angular router listens to URL changes and maps them to components:

URL /                → renders Home component
URL /browse          → renders Browse component
URL /search?q=sci-fi → renders SearchResults component
URL /movies/550      → renders MovieDetail component
URL /watchlist       → renders Watchlist component

This mapping is defined in your route configuration (covered in the next lesson). The router reads the current URL, finds the matching route, and renders the component in a <router-outlet> placeholder.

Server configuration for SPAs

There is one catch: if a user navigates directly to /movies/550 (by typing it in the address bar or refreshing the page), the server receives a request for /movies/550. If the server is not configured to return index.html for all routes, it returns a 404.

The fix is to configure the server to return index.html for any path it does not have a file for. GitHub Pages handles this automatically. Other hosting platforms require a redirect rule. Angular’s ng build documentation covers the specifics for popular hosts.

Exercise

No code yet — this lesson is conceptual. Answer:

1. When a user clicks a link in a traditional website, what does the browser do? When the same link is clicked in an SPA, what happens instead?
2. What is the browser’s History API, and why does it matter for client-side routing?
3. If a user refreshes the page at /movies/550 in a SPA, what problem might occur, and what is the fix?

Recap

• SPAs manage navigation with JavaScript rather than server requests, using the browser’s History API.
• The Angular router listens to URL changes and renders the matching component in <router-outlet>.
• Navigation in SPAs is instant because no new HTML is downloaded.
• Servers hosting SPAs must be configured to serve index.html for all routes (the “fallback” or “catch-all” configuration).