Angular Expansion Panel — Collapsed Panels Block Main Thread

I watched a team ship an Angular dashboard with 40 expansion panels, every single one eagerly loading its full dataset on page init. The page took 11 seconds to become interactive. Not because the panels were wrong — because nobody thought about what 'open' and 'closed' actually mean at runtime.

Angular Material's mat-expansion-panel is deceptively simple to drop into a template. Slap it in, add a title, dump your content inside — it works. But 'it works' and 'it works correctly under real load with real state management' are two completely different sentences. The accordion pattern specifically introduces coordination problems: which panel is the source of truth for open/closed state? Who manages multi-panel exclusivity? What happens when your backend data arrives after the panel is already rendered? What happens when Angular's change detection is running across 40 hidden panel subtrees on every keystroke? These aren't edge cases. They're the default conditions in any production app.

By the end of this, you'll be able to build an accordion that handles dynamic panel lists, controls open/closed state programmatically from outside the component, implements true lazy content loading so panels don't fetch data until opened, and wires correctly into reactive forms and route-based state. You'll also know exactly when to rip the whole thing out and reach for something simpler — and what 'simpler' actually looks like in Angular 17 and 18 with signals in play.

The mat-accordion Trap: Who Actually Owns the State?

The first thing most developers miss is that mat-accordion and mat-expansion-panel have a surprisingly loose relationship. mat-accordion is a coordinator, not a container. It doesn't hold state — it enforces a policy (single open panel) by listening to its panel children via a ContentChildren query. The moment you break that parent-child DOM relationship — say, you render panels dynamically inside an *ngFor with a structural directive in between, or you wrap conditional panels in a div — the accordion loses awareness of some panels entirely and the single-open guarantee silently breaks. Both panels stay open. No warning. No error. The bug is invisible until a user reports it.

This is why accordion state doesn't belong in the template. The open/closed state of each panel is business logic. It answers questions like: 'Which section was the user reviewing when they navigated away?' 'Should the error section auto-expand when validation fails?' 'Which panel should be open when the user lands on this page from an email deep link?' None of those questions can be answered by template-level boolean bindings that exist only in memory.

The correct production pattern: maintain an explicit activePanelId identifier in your component — a plain string in Angular 14-16, or a signal in Angular 17+. Drive [expanded] from that identifier. Handle (opened) and (closed) events to update the identifier. Your accordion state is now testable, serialisable to the URL, restorable on page refresh, and accessible to any service or store that needs to read or set it from outside the component.

Angular 17 introduced signals as a stable API, and they change the ergonomics here noticeably. A signal<string>('') as your activePanelId integrates naturally with OnPush — reading the signal inside the template creates a reactive dependency automatically, and updating the signal schedules a re-render without calling markForCheck() manually. For new projects on Angular 17+, prefer signals for accordion state. For existing projects on Angular 14-16, the plain string pattern below is fully correct and requires no migration.

Lazy Panel Content: Stop Loading What Users Never Open

Here's the 11-second page I mentioned. The team was loading full transaction history, chart data, and analytics summaries inside panels that 90% of users never opened. All of it fetched eagerly on page load. All of it blocking the thread with change detection cycles across thousands of DOM nodes that were visually hidden behind Material's CSS.

Angular Material solves this with <ng-template matExpansionPanelContent>. Content inside this directive is not rendered to the DOM until the panel first opens — not before. This isn't CSS display:none with the component hidden behind it. The component is never instantiated. Its ngOnInit hook never fires. The HTTP calls inside it are never made. The change detection subtree for that component simply doesn't exist until the user opens the panel.

The catch that consistently surprises developers: 'first opens' is exact. Once opened, the content stays in the DOM even after the panel closes again. The component is alive, subscribed, and visible to change detection — it's just visually hidden by Material's panel close animation. This is the persistence guarantee, and it's a feature for data display. But for a form inside a panel that should start fresh each time, it's a bug.

If you need content destroyed on close — to reset a form, clear a wizard state, or force a re-fetch of live data — you need *ngIf="activePanelId === section.id" on the panel body instead. This destroys the component on close and creates a new instance on reopen. The form state resets because the component is new. The HTTP call re-fires because ngOnInit runs again on the fresh component.

Angular 17 introduces @defer as a template syntax alternative for lazy loading. For panels that load heavy components — charting libraries, rich text editors, map components — @defer (on interaction) paired with the panel header interaction can defer loading the heavy dependency entirely until the user opens the panel, not just defer instantiation. This is a step beyond matExpansionPanelContent, which defers instantiation but still requires the component's module to be bundled eagerly. @defer can split the bundle entirely.

Programmatic Control and Reactive Form Integration That Doesn't Leak

At some point your product manager will say: 'When the user hits Submit and there's a validation error, automatically open the section with the error.' This is where most accordion implementations crack. The component was designed to be user-driven. Now you need to drive it from code, and there are exactly two ways to do that — one of which creates a memory leak.

The leak-prone way: grab a @ViewChild(MatExpansionPanel) reference and call .open() directly. Fine for one static panel. Falls apart the moment you have a *ngFor list of panels, because @ViewChildren gives you a QueryList — and QueryList.changes is a cold observable that you need to unsubscribe from yourself. I've seen this exact pattern create zombie subscriptions in a settings page that reloaded its panel list on every navigation. Memory climbed 40MB per minute in production until someone noticed Chrome's task manager crawling.

The correct way: drive state through [expanded] bindings. Your validation logic sets activeSectionId to the first section with errors. The template responds. No ViewChild. No imperative .open(). No subscription to manage. No ngOnDestroy cleanup required.

The form-to-accordion wiring pattern below uses a controlSectionMap — a plain object that maps each form control name to the section it lives in. When submit fires, markAllAsTouched() makes all error states visible, then isSectionInvalid() scans the map to find which section has the first invalid control. Setting activeSectionId to that section ID opens it. The error message is already visible inside the panel because the control is touched and invalid. This is the entire flow — no DOM manipulation, no ViewChild, no subscription.

When to Ditch mat-expansion-panel and Just Use a div

Angular Material's expansion panel ships with the full Material theming system, ripple effects, ARIA roles (role="button", aria-expanded, aria-controls), keyboard navigation (Enter, Space, Tab, Arrow keys), and a JavaScript animation player. That's roughly 15KB of JavaScript in your bundle before tree-shaking, plus one JS animation player registered with Angular's animation engine per panel instance — even collapsed panels contribute to the engine's bookkeeping.

For most dashboard and settings UIs with under 20 panels, that trade-off is completely reasonable. You'd build the ARIA scaffolding and keyboard navigation yourself anyway, and Material does it correctly. The bundle cost is amortized across the rest of your Material component usage.

But there are specific scenarios where it's the wrong choice, and they come up more often than you'd expect.

The high-panel-count case: I watched a fintech mobile app try to render 60 expansion panels on a single compliance document viewer page using mat-expansion-panel. Material's animation system created 60 JS animation players simultaneously. On mid-range Android devices (the demographic that matters most for fintech in many markets), opening any panel triggered 380ms of scripting work — far above the 16ms frame budget. The fix was replacing mat-expansion-panel with CSS max-height transitions on a div, backed by a Set<string> for state. Same visual result. Zero Material animation overhead. Jank dropped from 380ms to under 16ms on the same device.

The SSR/SEO case: if you're building a landing page FAQ accordion where the content needs to be indexed by search engines, mat-expansion-panel is the wrong tool. It requires Angular's runtime to render, which means Angular Universal or the new Angular 17 SSR with hydration. Native <details> and <summary> elements render on the server with zero JavaScript, are indexed correctly by Googlebot, and are accessible by default. For marketing content, there's no argument for a JavaScript accordion.

The bundle-sensitive micro-frontend case: if your app is composed of independently deployed Angular micro-frontends with strict bundle size limits, importing MatExpansionModule for a simple FAQ list in one shell consumes budget that should go to application code. CSS max-height with manual ARIA attributes costs literally 0KB of JavaScript.

Frequently Asked Questions