withInMemoryScrolling in Angular: Modern Scroll Restoration and Anchor Scrolling Explained

Single-page applications (SPAs) fundamentally changed web navigation by eliminating full page reloads. However, this architectural shift introduced a UX regression: browsers lost their native ability to restore scroll positions when users navigate backward or forward through history. In traditional multi-page applications, the browser automatically remembers where you scrolled on a page and returns you to that exact position when you hit the back button. SPAs broke this behavior.

Angular’s withInMemoryScrolling feature addresses this gap by giving the router control over scroll behavior during navigation. It provides declarative configuration for two critical scroll-related features: scroll position restoration across route changes and fragment-based anchor scrolling.

Developers should care about this feature when building applications where users frequently navigate between routes and expect intuitive scroll behavior — particularly in content-heavy applications, e-commerce platforms with list-detail patterns, dashboards with tabbed interfaces, or any application where preserving navigation context improves usability.

What is withInMemoryScrolling

withInMemoryScrolling is a router feature function introduced in Angular’s standalone API era that enables the router to manage scroll behavior during navigation events. The “in-memory” designation refers to how Angular stores scroll positions: it maintains a map of scroll positions in memory, keyed by navigation state, rather than relying on browser-native mechanisms.

At the router level, this works through integration with Angular’s navigation lifecycle. When a navigation begins, the router captures the current scroll position. When a navigation completes, it determines whether to restore a previous position, scroll to top, scroll to an anchor, or leave the scroll position unchanged. This decision is made based on the configuration options and the navigation context (forward navigation, back navigation, route reload, etc.).

The critical difference between browser default scrolling and Angular router-controlled scrolling lies in control and consistency. Browser scroll restoration works at the document level and can be unreliable in SPAs where the DOM is dynamically replaced. Angular’s approach operates within the application’s routing context, providing deterministic behavior that accounts for lazy loading, route transitions, and application-specific navigation patterns.

Configuration in Modern Angular

In modern Angular applications using standalone components and the provideRouter API, withInMemoryScrolling is configured as a router feature alongside other router capabilities.

import { ApplicationConfig } from ‘@angular/core’;
import { provideRouter, withInMemoryScrolling } from ‘@angular/router’;
import { routes } from ‘./app.routes’;

export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(
      routes,
      withInMemoryScrolling({
        scrollPositionRestoration: ‘enabled’,
        anchorScrolling: ‘enabled’
      })
    )
  ]
};

In the standalone bootstrap approach:

import { bootstrapApplication } from ‘@angular/platform-browser’;
import { provideRouter, withInMemoryScrolling } from ‘@angular/router’;
import { AppComponent } from ‘./app/app.component’;
import { routes } from ‘./app/app.routes’;

bootstrapApplication(AppComponent, {
  providers: [
    provideRouter(
      routes,
      withInMemoryScrolling({
        scrollPositionRestoration: ‘enabled’,
        anchorScrolling: ‘enabled’
      })
    )
  ]
});

The withInMemoryScrolling function accepts a configuration object with two primary options:

scrollPositionRestoration: Controls how scroll positions are managed during navigation. Accepts 'disabled', 'enabled', or 'top'.

anchorScrolling: Enables or disables automatic scrolling to fragment identifiers in URLs. Accepts 'enabled' or 'disabled'.

Scroll Restoration Strategies

‘disabled’

This strategy completely disables Angular’s scroll management. The scroll position remains wherever it was when navigation occurs. This is the default behavior if withInMemoryScrolling is not configured.

Use cases for 'disabled':

• Applications implementing custom scroll behavior

• Infinite scroll implementations that manage their own position

• Single-route applications where scroll restoration isn’t relevant

• Performance-critical applications minimizing router overhead

UX implications: Users navigating back will stay at the top of the previous page rather than returning to their prior position. This can be disorienting in list-detail patterns.

withInMemoryScrolling({
  scrollPositionRestoration: ‘disabled’
})

‘enabled’

This strategy restores scroll positions when navigating backward or forward through browser history, but scrolls to the top on new forward navigations. This mimics traditional browser behavior in a SPA context.

Use cases for 'enabled':

• E-commerce platforms with product listings

• Content management systems

• Any list-to-detail navigation pattern

• Applications where users browse and return frequently

UX implications: Provides intuitive navigation experience consistent with traditional websites. Users expect to return to their scroll position when hitting back, which this strategy delivers.

withInMemoryScrolling({
  scrollPositionRestoration: ‘enabled’
})

‘top’

This strategy always scrolls to the top of the page on every navigation, regardless of direction.

Read the Complete Article on Medium

This post is a condensed overview of Angular’s withInMemoryScrolling feature.

The full, in-depth article on Medium includes:

• Complete explanation of scroll restoration in SPAs

• Angular Router lifecycle and internal behavior

• Real-world use cases (list → detail → back, dashboards, content pages)

• Edge cases (lazy loading, SSR, hydration, virtual scroll conflicts)

• Performance and accessibility considerations

• Step-by-step demo walkthrough

• Sample code and configuration examples

Read the full article, explore the demo, and access the complete code here:
Read Full Article

**🎯 Your Turn, Devs!

👀 Did this article spark new ideas or help solve a real problem?

💬 I’d love to hear about it!

✅ Are you already using this technique in your Angular or frontend project?

🧠 Got questions, doubts, or your own twist on the approach?

Drop them in the comments below — let’s learn together!

---

🙌 Let’s Grow Together!

If this article added value to your dev journey:

🔁 Share it with your team, tech friends, or community — you never know who might need it right now.

📌 Save it for later and revisit as a quick reference.

---

🚀 Follow Me for More Angular & Frontend Goodness:

I regularly share hands-on tutorials, clean code tips, scalable frontend architecture, and real-world problem-solving guides.

• 💼 LinkedIn — Let’s connect professionally

• 🎥 Threads — Short-form frontend insights

• 🐦 X (Twitter) — Developer banter + code snippets

• 👥 BlueSky — Stay up to date on frontend trends

• 🌟 GitHub Projects — Explore code in action

• 🌐 Website — Everything in one place

• 📚 Medium Blog — Long-form content and deep-dives

• 💬 Dev Blog — Free Long-form content and deep-dives

• ✉️ Substack — Weekly frontend stories & curated resources

• 🧩 Portfolio — Projects, talks, and recognitions

• ✍️ Hashnode — Developer blog posts & tech discussions

• ✍️ Reddit — Developer blog posts & tech discussions

---

🎉 If you found this article valuable:

• Leave a 👏 Clap

• Drop a 💬 Comment

• Hit 🔔 Follow for more weekly frontend insights

Let’s build cleaner, faster, and smarter web apps — together.

Stay tuned for more Angular tips, patterns, and performance tricks! 🧪🧠

✨ Share Your Thoughts To 📣 Set Your Notification Preference