The Router's Signal Era In short: The router changed less than the rest of Angular — routes, guards, and outlets all work the same way. But a handful of additions removed the most repetitive parts, and one of them is arguably the best small feature in modern Angular. — turn this on today The old way to read a value from the address bar was four lines of setup code in every routed component: Note the — says "might be missing" even for a value the route guarantees. And you had to subscribe rather than read once, because moving from to reuses the same component without running again. Forgetting that is one of the classic Angular bugs. With one line of setup: route values, query values, route data, and resolved values all arrive as ordinary inputs: Because they are signals, moving from to updates , which makes the resource fetch again. The component-reuse bug is gone by design — there is no lifecycle method left to forget. Names must match: an input called connects to the part of the address or an value. If you turn on one thing from this chapter, turn on this. — reactive route matching (v22) Highlighting the current menu item used to mean either in the template (fine, but template only) or subscribing to router events: v22 gives you a signal directly: The value is being able to build on route state in a , which router events never allowed cleanly. View transitions Angular connects page changes to the browser's built-in transition feature, so moving between pages fades by default and can be styled in CSS. Browsers without support just change page normally — no extra code, no fallback to write. For animating a shared element between pages: Route-level providers and cleanup Covered in Chapter 2, but the routing side is worth repeating: providers on a route give you a service tied to that part of the app, created when you arrive and destroyed when you leave — with no module . Historically these were not always destroyed when you navigated away, which leaked memory. v21.1 added a fix you opt into: Smaller changes worth knowing Redirects that can decide (v18). accepts a function: Wildcards with a tail (v21.1). now works — before, had to be last. Trailing slash handling (v21.2). New strategies let you make addresses consistent, which matters for search engines. The router as a source of signals. With and input binding, most components no longer need or at all. Injecting to navigate is normal. Injecting to read is now a smell. "But doesn't ngOnInit run on every page change?" It does not, and this is one of the oldest and most persistent Angular bugs. The fact: when you go from to , Angular reuses the same component . Same route, same component — no destroy, no create, no . This is a deliberate speed decision and it is correct. So this loads invoice 1 and never anything else: It works perfectly when you arrive by refreshing or from another page. It only fails when moving between two invoices — which is exactly what a "next invoice" button does. The bug reaches production constantly because the obvious test path never hits it. With input binding, the trap stops existing: is a signal. Navigation updates it. The resource fetches again. There is no lifecycle method to get wrong, because there is no lifecycle method. The architect's view Here is the shape of the problem this solves, and it is worth seeing in full because it is an API design lesson as much as a routing one. Consider three components on the same route, each reading route values a different way — written by different people at different times: All three look reasonable. Only one is correct. B works. A goes stale, because navigating between two records reuses the component and never re-runs . C updates and leaks — it collects a new subscription on every visit, so after a few navigations it fires several times per change, with whichever reply lands last winning. The symptom a user reports is "sometimes the panel shows the wrong record's data." Tracing that back to three different route-reading styles is slow work. The fix: The real lesson is about API design, not routing. Nobody wrote bad code here. The old API offered three reasonable-looking approaches with different correctness properties, and nothing marked which was which. Two of them were traps that only spring under specific navigation patterns. That is the situation to recognise and eliminate wherever you find it. When an API has several plausible usages and only one is right, the mistakes are not a training problem — they are a design problem, and the fix is to remove the choice. Input binding leaves one way, and it is correct by construction: No , so it cannot go stale on component reuse No subscription, so it cannot leak No marks, because required inputs are properly typed Route values feed and directly What it buys, on each axis. Maintainability : one pattern instead of three, less code, and largely disappears from components. Correctness : two whole failure modes become unreachable. Onboarding : a j…