We’ve built the data pipeline (Part 1) and the dashboard UI (Part 2). The app works. But “works” and “feels amazing” are two very different things.

The Invisible Upgrades That Make Everything Feel Premium

In this final Phase 3A post, we tackle two framework-level optimizations that elevate our application from functional to polished: View Transitions and Incremental Hydration.

1 ✨ View Transitions: Cinematic Route Changes

1.1 The Problem

By default, when a user navigates between routes, the old view instantly disappears and the new view instantly appears. It’s functional, but it feels abrupt — like flipping a light switch.

1.2 The Solution

The View Transitions API is a browser-native feature that Angular can hook into. It creates a smooth, animated crossfade between the outgoing and incoming route.

Enabling it is a single line:

// app.config.ts
provideRouter(
  routes,
  withComponentInputBinding(),
  withViewTransitions(),   // ← This is all you need
),

1.3 How It Works Under the Hood

sequenceDiagram
    participant U as User
    participant R as Router
    participant API as View Transitions API
    participant DOM as Browser DOM

    U->>R: Navigates to /settings
    R->>API: document.startViewTransition()
    API->>DOM: Captures "old" snapshot
    R->>DOM: Swaps route components
    API->>DOM: Captures "new" snapshot
    API->>DOM: Crossfade animation (old → new)
    DOM->>U: Smooth visual transition

The Teaching Moment: You get this for free. No custom animations, no third-party libraries, no @angular/animations. The browser handles the visual interpolation natively, which means it’s GPU-accelerated and buttery smooth.

1.4 Customizing with CSS

You can style the transition using the ::view-transition-old and ::view-transition-new pseudo-elements:

::view-transition-old(root) {
  animation: fade-out 0.2s ease-out;
}

::view-transition-new(root) {
  animation: fade-in 0.3s ease-in;
}

2 🧊 Incremental Hydration: SSR, Evolved

2.1 What Changed

In Phase 1, our app.config.ts used withEventReplay() — a basic SSR hydration strategy. In Phase 3A, we upgraded to:

provideClientHydration(
  withIncrementalHydration(), // Replaces withEventReplay()
),

2.2 What is Hydration?

When using Server-Side Rendering (SSR) or Static Site Generation (SSG), the server sends fully rendered HTML to the browser. But that HTML is “dead” — it has no event listeners, no interactivity. Hydration is the process of making it alive.

2.3 The Evolution

graph TD
    subgraph "Traditional Hydration"
        ServerHTML1["Server HTML (static)"] --> FullHydrate["Hydrate EVERYTHING at once"]
        FullHydrate --> Interactive1["Fully Interactive"]
    end

    subgraph "Incremental Hydration"
        ServerHTML2["Server HTML (static)"] --> Visible["Hydrate visible components first"]
        Visible --> Interactive2["Above-the-fold is interactive"]
        Interactive2 --> Deferred["Hydrate remaining on trigger"]
        Deferred --> FullInteractive["Fully Interactive"]
    end

2.4 Why It Matters

In a dashboard with many widgets (KPI cards, charts, tables, notifications), traditional hydration would hydrate everything at once — even components the user hasn’t scrolled to yet. This blocks the main thread and delays Time-to-Interactive (TTI).

Incremental Hydration defers the hydration of off-screen or low-priority components until they are actually needed. It works hand-in-hand with @defer blocks:

@defer (on viewport; hydrate on viewport) {
<app-heavy-chart-widget />
} @placeholder {
<div class="chart-skeleton">Loading chart...</div>
}

The component’s HTML exists in the server-rendered output, but it only becomes interactive when the user scrolls it into view.

3 📐 The Full app.config.ts at Phase 3A

Here’s the complete configuration after all Phase 3A upgrades:

export const appConfig: ApplicationConfig = {
  providers: [
    provideZonelessChangeDetection(), // Phase 1
    provideRouter(
      routes,
      withComponentInputBinding(), // Phase 3A — NEW
      withViewTransitions(), // Phase 3A — NEW
    ),
    provideClientHydration(
      withIncrementalHydration(), // Phase 3A — UPGRADED
    ),
    provideHttpClient(withInterceptors([authInterceptor, loggingInterceptor])),
    // ...DI providers (Phase 1)
    { provide: ErrorHandler, useClass: GlobalErrorHandler },
  ],
};

4 🎓 The Teaching Moment: Configuration as Documentation

Notice how our app.config.ts tells a story. Each provider, each with*() function, is a deliberate architectural decision. By reading this single file, a new developer on the team can understand:

• We don’t use Zone.js.
• Our routes bind data directly to component inputs.
• Our navigation transitions are animated.
• Our SSR uses incremental hydration.

This is Configuration as Documentation — and it’s one of the hallmarks of enterprise-grade Angular.

5 🏁 Phase 3A Complete!

Let’s recap what we accomplished:

Next up: Phase 3B, where we deep-dive into Angular’s resource() API for reactive, cancelable data fetching.

Curious about how these features interact? The beauty is in the app.config.ts — one file, three lines, three massive UX improvements. Check it out on GitHub!