DEV Community: Amanulla Khan

9 Mistakes Teams Keep Making When Migrating Legacy Angular Apps (2026 Edition)

Amanulla Khan — Tue, 28 Jul 2026 18:49:16 +0000

Angular has changed more in the last three years than in the five before that. Standalone components have been the default for new Angular applications since v19, built-in control flow (@if/@for) has been stable since v17, signals are now a core part of Angular's modern reactivity model, zoneless change detection is the default for new apps in v21+, and as of v22 OnPush is the default change detection strategy. If your app was last touched seriously back in the NgModule-and-*ngIf era — or worse, it's still a hybrid AngularJS app — the migration path is no longer "run ng update and fix whatever breaks."

A note on how to read this: where a claim rests on specific framework behavior I've linked the primary source — an Angular RFC, a filed issue, or the official docs — rather than asking you to take my word for it, because a couple of these contradict advice that's currently circulating.

Below are the mistakes I keep seeing on real migration projects, roughly in the order they bite you.

1. Treating the migration as a single "big bang" project

The most expensive mistake happens before anyone writes code: deciding to freeze feature work for months and rewrite everything at once.

Angular's own tooling assumes the opposite. ng update enforces one major version at a time — you cannot jump from v14 to v22 directly. Each hop (14→15→16→17→18→19→20→21→22) runs its own schematics. This isn't a style preference, it's enforced: Angular's release documentation states you can ng update to any version "provided that... the version you want to update from is within one major version of the version you want to upgrade to" — with a worked example of going 10 → 11 → 12 rather than 10 → 12 directly. A "big bang" plan collides with this immediately: teams try to jump straight to the latest major, ng update refuses or gets --force'd into a broken state, and someone spends a week bisecting which of six simultaneous major upgrades caused the regression.

The fix is the strangler pattern applied to versions, not just code: upgrade one major version, run the automated migrations for that version, ship it, then move to the next. The cost of deferral isn't linear either — breaking changes compound, so a team that skipped five years of upgrades isn't facing five times the work of a team that skipped one.

For a genuinely legacy (AngularJS 1.x) app, the equivalent mistake is trying to rewrite the whole SPA before shipping anything. The usual advice is a hybrid app via UpgradeModule, migrating route-by-route behind a shared shell. That still works — but go in knowing something the guides rarely mention: ngUpgrade and zoneless don't currently mix. A team that tried it on Angular 19 + AngularJS 1.8 found change detection simply didn't fire for downgraded components, and an Angular team member investigating replied that "the upgrade module appears to depend on ZoneJS," pointing at specific code, while adding that enabling zoneless support "likely carries some amount of risk since there's so little usage left of the upgrade adapter that it's effectively untested" (angular#61640).

I'd read that as "unsupported and untested," not "architecturally impossible" — nobody has declared it permanently off the table. But for planning purposes the distinction doesn't help you much: an untested path through a low-usage compatibility layer is not where you want your migration's critical path. The practical takeaway is that the hybrid phase and zoneless are sequential, not concurrent, and that second quote is the real signal — ngUpgrade is in maintenance territory. The bridge is one you need to actually finish crossing, not a steady state to park in for three years.

2. Running the standalone/control-flow schematics and assuming they're correct

ng generate @angular/core:standalone and ng generate @angular/core:control-flow are genuinely good tools — but they're pattern-matching schematics, not compilers with full semantic understanding of your templates. Mishandled ng-template removal is a whole genre of filed bug, not a one-off: #52513, #53288, #53362, #53383, #59919, and #64741 are all variations on the schematic deleting or mangling a template that was still needed.

Most of those specific reports are now fixed, and that's the point rather than a caveat: the same failure mode kept resurfacing in new shapes across several years of releases, because "is this template still referenced?" is a genuinely hard question to answer from pattern matching. Your codebase's particular shape is not guaranteed to be one of the ones somebody already filed.

The nastiest variant is when the template is referenced from TypeScript rather than another template, because nothing in the converted markup looks wrong:

// Before migration
template: `
  <div *ngIf="true; else someTpl"></div>
  <ng-template #someTpl />
`
export class CountComponent {
  someTpl = viewChild('someTpl', { read: ViewContainerRef });
}

The schematic converts the *ngIf to @if/@else and removes the <ng-template #someTpl /> — leaving the viewChild query pointing at a template reference that no longer exists (#59919). The template compiles; the query silently returns nothing at runtime; whatever dynamic rendering depended on that ViewContainerRef quietly stops working.

What to actually do: the schematic's own README says to verify the application between each step, and it accepts a path option specifically so large apps can migrate a subdirectory at a time. Use both. Diff every changed template by hand, grep for viewChild/ViewChild/ngTemplateOutlet references to any template the migration touched, and don't merge until you've visually verified each converted view — not just that it compiles. Treat the automated migration as a first draft, not a merge-ready PR.

3. Flipping to zoneless without auditing implicit change-detection triggers

Angular 21 makes zoneless the default for new apps, and it's increasingly the target for migrated ones too, because it removes an entire class of Zone.js monkey-patching overhead and makes change detection explicit and predictable.

The useful way to think about the risk is not "async code stops working" — that's the version of this warning you'll see repeated everywhere, and it's too broad to act on. Zoneless doesn't care whether your code is asynchronous. It cares whether Angular gets notified. Angular's docs list seven conditions that schedule change detection (including edge cases like attaching a dirty view, removing a view, and registering a render hook); these are the ones that matter day to day:

a signal that's read in a template is updated
ChangeDetectorRef.markForCheck() is called
ComponentRef.setInput() is used
a template-bound event listener fires — your (click), (input), (submit) handlers are all fine
AsyncPipe receives a new value That last point is the whole model in miniature. Angular needs an explicit notification that a view may need updating. A signal write can provide that notification when the signal is read in the template; AsyncPipe calls markForCheck() for you when its observable emits. Other Angular APIs, such as ComponentRef.setInput() and bound template listeners, can also schedule change detection. A hand-rolled subscription that simply assigns a new value to a plain property does none of those things.

That distinction is what makes the risk auditable. What breaks is state that changes with no notification attached — a bare setTimeout or setInterval callback, a Promise.then, a manually-registered addEventListener outside the template, a WebSocket onmessage, or a third-party SDK callback, each assigning to a plain property:

// This pattern is everywhere in legacy Angular code
setTimeout(() => {
  this.status = 'ready'; // Zone.js used to notice this; nothing does now
}, 300);

That assignment updates a plain property, and nothing tells Angular a check is needed — the UI silently goes stale. The fix isn't a shim, it's a real architectural change: back that state with a signal() (or push updates through ChangeDetectorRef.markForCheck() at minimum) so the framework has an explicit reason to update the view.

status = signal<'loading' | 'ready'>('loading');

setTimeout(() => this.status.set('ready'), 300);

Note the direction of travel here: an existing app doesn't become zoneless because you upgraded. It keeps its Zone.js behavior until somebody deliberately turns Zone.js off — which means this is a migration you opt into on your own schedule, and therefore one that's easy to defer indefinitely and easy to do carelessly in a quiet sprint by whoever picks up the "remove zone.js" ticket. Before that ticket gets merged, grep your codebase for setTimeout, setInterval, third-party callbacks, and WebSocket handlers that mutate component state — every one of them is a candidate for silent breakage. Also budget time for your UI kit: Material and PrimeNG components historically had zoneless gaps, so pin to versions explicitly tested against the Angular version you're targeting rather than assuming "latest" works.

4. Letting the `OnPush` migration quietly make your debt permanent

First, a correction to something you'll read on a lot of migration blogs: zoneless does not require OnPush. Angular's own zoneless guide is explicit — "The OnPush change detection strategy is not required, but it is a recommended step towards zoneless compatibility." Default-strategy components are still checked in a zoneless app, provided something notifies Angular that a check is needed. If your app breaks after going zoneless, the cause is a missing notification (mistake #3), not a missing OnPush.

The real trap is on the other side, and it already landed. As of v22, per the release's own breaking-changes note, "Component with undefined changeDetection property are now OnPush by default" — the old default is now spelled ChangeDetectionStrategy.Eager (RFC #66779; v22.0.0 release notes). And — exactly as with the standalone migration — the Angular team ships an automatic migration that preserves your behavior. The v22 release describes it as a migration to "add ChangeDetectionStrategy.Eager where applicable," and it runs as part of ng update — so components that were relying on the old implicit default come out the other side carrying an explicit Eager annotation. ("Where applicable" is the release's own wording, so don't assume the annotation count will exactly match your component count; read the diff.)

That migration is the correct engineering decision by the framework team, and it is also the moment your technical debt becomes invisible. Before it runs, "this component is on the default strategy" is an absence — something you can grep for and gradually fix. After it runs, every one of those components carries an explicit, intentional-looking Eager annotation that no future reviewer will question, because it looks like somebody chose it.

So don't just accept the migration diff and move on. Run it, then treat the resulting Eager annotations as a tracked backlog rather than settled code — they're a precise, machine-generated inventory of every component that was never designed for OnPush. Work through them leaf-components-first; the conversion usually surfaces genuine mutation bugs (arrays and objects mutated in place instead of replaced) that were already latent.

5. Carrying over unmanaged RxJS subscriptions

This one predates zoneless, but the migration is the right moment to deal with it: legacy services and components that call .subscribe() in ngOnInit with no takeUntil, no takeUntilDestroyed(), and no async pipe accumulate leaked subscriptions. Repeated destruction and recreation of the component can leave another live subscription behind, holding a reference to the destroyed instance — a memory leak, plus duplicated side effects (double-fired analytics, double-submitted requests) that get harder to trace the longer the session runs. The distinction that matters is whether the source completes: a one-shot HttpClient call tears its own subscription down, so it's the long-lived streams that bite you — a BehaviorSubject in a service, router events, fromEvent, a WebSocket feed.

// Legacy pattern — currentUser$ never completes, so this
// subscription outlives the component on every re-navigation
ngOnInit() {
  this.userService.currentUser$.subscribe(u => this.user = u);
}

// Modern pattern
private destroyRef = inject(DestroyRef);

ngOnInit() {
  this.userService.currentUser$
    .pipe(takeUntilDestroyed(this.destroyRef))
    .subscribe(u => this.user.set(u));
}

If you're migrating anyway, this is the moment to convert hand-rolled subscription management to takeUntilDestroyed(), the async pipe, or toSignal() — not just to modernize syntax, but because the old pattern is an active liability once the CD model changes underneath it.

6. Skipping the DI audit when partially migrating to standalone

Scope first, because this one gets overstated: if your service is providedIn: 'root', none of this applies to you. It resolves against the root environment injector no matter who injects it, and standalone conversion doesn't change that. Angular has recommended providedIn as "the best practice for providing services" since v6, so in a reasonably modern codebase most services are already safe.

The exposure is services registered the old way — listed in an @NgModule.providers array, typically behind a CoreModule or a SomeModule.forRoot(). That pattern already had a well-known duplication hazard in the NgModule world: provide a service in a module that gets imported by both an eagerly-loaded and a lazy-loaded module, and the lazy module's injector instantiates its own copy. forRoot() exists specifically as a convention to avoid it, and the classic CoreModule guard — inject the module into itself with @Optional() @SkipSelf() and throw if it's already there — exists to catch it when the convention is broken.

Standalone conversion adds a new way to trip the same wire, because it introduces new injector boundaries. If a provider-carrying NgModule is moved into a narrower injector scope during migration — most commonly by landing it in a standalone component's own imports array to satisfy that component's dependencies — a service that was previously resolved as one shared instance may now be instantiated more than once. The exact behavior depends on how the module and its providers are wired, but the risk is real: changing the injector hierarchy changes the lifetime and scope of services.

This isn't hypothetical, and it isn't a bug queued for a fix. The Angular team reviewed a report of exactly this — services from an NgModule's providers duplicating across standalone components that imported it — and closed it as working as designed (#53120).

The failure is nasty because it doesn't look like a DI problem. Two copies of CartService means the header reads one instance and checkout reads another; the symptom is "the cart shows 2 items up top and 0 at checkout," which gets triaged as a state-sync bug and debugged as one, sometimes for days, because nobody suspects the injector topology moved.

The fix is to hoist, not to sprinkle. Provider-carrying modules belong at application level, not in component imports:

// Risky during migration: pulling a provider-carrying NgModule
// into a component introduces a narrower provider scope.
@Component({ imports: [CoreModule], /* ... */ })

// Migration approach: hoist NgModule providers to the
// application/environment injector instead.
bootstrapApplication(AppComponent, {
  providers: [importProvidersFrom(CoreModule)],
});

importProvidersFrom() is the bridge API for exactly this, and its type signature makes the intended scope explicit. It returns EnvironmentProviders, and Angular's docs state that providers extracted this way "are only usable in an application injector or another environment injector (such as a route injector). They should not be used in component providers."

It's a fine migration step, but treat it as a stepping stone rather than a destination — it only carries providers, so anything else the module was doing (initialization logic, guards) needs somewhere to live. The end state most teams want is a plain provideCore() function returning a Provider[], with module-constructor side effects moved to an initializer. Before you convert a single component, grep for @NgModule.providers arrays and forRoot( — that list is your risk register.

7. No regression safety net before refactoring

Teams that skip continuous testing during migration aren't cutting a corner, they're removing the only thing that would tell them the migration is wrong. This shows up constantly on real projects: TestBed configurations built for NgModule-declared components don't automatically work for standalone ones (imports vs declarations semantics differ), so the test suite either silently stops covering what it used to, or fails to compile and gets .skip()'d "temporarily" — which becomes permanent.

Before touching template syntax or component architecture, get characterization tests (even coarse E2E ones with Cypress/Playwright) around the critical user flows. They don't need to be elegant; they need to fail loudly when the migration breaks behavior that unit tests, written against the old structure, won't catch because they get rewritten alongside the code they're testing.

8. Letting CI/CD quietly block the upgrade

Angular's version requirements move fast, and the minimum-patch precision catches people out. Per Angular's own version compatibility reference, v20 and v21 both require Node ^20.19.0 || ^22.12.0 || ^24.0.0 — note that's 20.19, so a runner pinned to Node 20.18 fails even though it's "on Node 20." v22 raises the floor again to ^22.22.3 || ^24.15.0 || ^26.0.0, dropping Node 20 entirely. Each major typically bumps the minimum TypeScript version too. The mistake is discovering this in CI after the code changes are already merged to a branch, because the pipeline's Node image was pinned two years ago and nobody owns updating it. This isn't a framework problem, it's an infrastructure-ownership gap — but it blocks the migration just as effectively as a code bug, and it's invisible until someone actually tries to run ng update.

Check your CI runner's Node/TypeScript versions against the target Angular version's requirements before scheduling the migration work, not after the PR is open.

9. Rewriting state management ad hoc, component by component

Legacy Angular apps accumulate state handling organically: some data lives in BehaviorSubjects in services, some in @Input()/@Output() chains, some in route resolvers, some in whatever global singleton someone added under deadline pressure. The mistake during migration is "fixing" this piecemeal — converting whichever service you happen to be touching to signals, NgRx SignalStore, or a plain signal-based store, with no shared decision about which pattern owns which category of state.

The result, eighteen months later, is a codebase with three competing state paradigms instead of one, which is strictly worse than the single legacy pattern it replaced because now every new developer has to learn which parts of the app use which model. Decide the target state architecture (signals for local/component state, a signal store or NgRx for shared/cross-cutting state, resolvers or route data for navigation-scoped state) before the migration starts, and treat inconsistency with that decision as a review blocker, not a style preference.

The pattern underneath all nine

Almost every mistake here comes from the same root cause: treating the migration as a mechanical version bump instead of an architectural decision with a safety net. The tooling (ng update, the standalone schematic, the control-flow migration) is good, but it's good at syntax transformation, not at verifying behavior or catching the assumptions your codebase quietly baked in around Zone.js, $scope, or singleton services. Budget the audit and testing time as part of the migration, not as cleanup afterward — it's cheaper every time.

Quick pre-migration checklist:

Confirm CI's Node/TypeScript versions meet the target Angular version's exact minimums (patch versions matter)
Grep for setTimeout/setInterval/raw callbacks mutating component state before turning Zone.js off
Inventory services in NgModule providers arrays before any standalone conversion — that's where duplicate-instance risk lives
After the v22 Eager migration runs, track the generated annotations as a backlog instead of treating them as settled code
Grep for viewChild/ViewChild/ngTemplateOutlet references to any ng-template the control-flow migration touched
Get coarse E2E coverage on critical flows before refactoring TestBed configs
Pick one target state-management pattern and write it down before the first PR
Upgrade one major version at a time — it's enforced, not advisory
If you're on an ngUpgrade hybrid, sequence it: treat zoneless as a step after AngularJS is gone, not alongside it

Micro Frontends in Angular: Single-SPA vs Module Federation (When Each One Actually Makes Sense)

Amanulla Khan — Sun, 12 Jul 2026 19:21:19 +0000

Micro frontends get pitched as the natural next step after microservices — split the UI the way you split the backend, ship teams independently, deploy without coordination. That pitch is half true. The other half is the part nobody puts in the conference talk: shared state headaches, duplicated bundles, version drift across teams, and a debugging story that gets meaningfully harder.

This article walks through the two dominant patterns for building Angular micro frontends — Single-SPA and Module Federation — with enough architectural detail to make a real decision, not just a demo that works on your laptop.

Before the how: should you even do this?

Micro frontends solve an organizational problem, not a technical one. The technical problem (one big Angular app is slow to build and risky to deploy) has cheaper fixes first: Nx monorepo with incremental builds, lazy-loaded standalone routes, esbuild-based builders. If a single team owns the app, none of those cheaper fixes are exhausted yet, and reaching for micro frontends first is usually premature.

Micro frontends earn their complexity when:

Multiple autonomous teams ship to the same product on independent release cadences
Different parts of the app genuinely need different tech stacks or major-version Angular/React/Vue coexistence
A monolith's build/deploy time has become an organizational bottleneck, not just an annoyance

If none of those are true, skip this article's implementation section and go fix your build pipeline instead. Assume from here that the organizational case is real.

Two different philosophies, not two flavors of the same thing

It's tempting to treat Single-SPA and Module Federation as interchangeable "micro frontend tools." They're not — they solve different layers of the problem.

	Single-SPA	Webpack Module Federation
What it actually is	A top-level router/orchestrator that mounts and unmounts independently-built apps	A build-time/runtime mechanism for one bundle to consume code from another bundle
Unit of composition	Whole applications (each with its own bootstrap lifecycle)	Individual modules/components, at any granularity
Framework agnosticism	Strong — mixes Angular, React, Vue, vanilla JS as siblings	Works across frameworks too, but composition is finer-grained and framework boundaries get blurrier
Routing ownership	Single-SPA owns top-level routing; each app owns its internal routing	No opinion on routing — you wire it yourself
Typical use case	"The dashboard is one app, billing is another, teams ship independently"	"This app needs a button-level component or a specific module from another team's build, sometimes even inside the same route"
Deployment model	Each app deployed independently, registered at a known URL/import map	Each "remote" deployed independently, exposed via a federation manifest
Maturity in Angular 20 workflow	Mature, but Angular Elements wrapping and zone coordination are manual work	Native Federation (via `@angular-architects/native-federation`) replaced Webpack-specific federation as the standard approach for esbuild-based Angular builds

In practice, most real Angular micro frontend architectures at enterprise scale use both: Single-SPA (or a simpler custom shell) for top-level app orchestration, and Module Federation for sharing specific components or libraries across those apps without duplicating them in every bundle.

Architecture at a glance

The shell doesn't know or care what's inside Dashboard or Billing. Dashboard and Billing independently pull a shared component (say, a notification bell or an auth-status widget) via Module Federation instead of each bundling their own copy.

Setting up the shell with Single-SPA

A minimal root config for an Angular-based shell looks like this:

// root-config.ts
import { registerApplication, start } from 'single-spa';

registerApplication({
  name: '@company/dashboard',
  app: () => System.import('@company/dashboard'),
  activeWhen: ['/dashboard'],
});

registerApplication({
  name: '@company/billing',
  app: () => System.import('@company/billing'),
  activeWhen: ['/billing'],
});

start({
  urlRerouteOnly: true,
});

Each micro frontend is bootstrapped as a Single-SPA "lifecycle" application — it exports bootstrap, mount, and unmount functions. For Angular, single-spa-angular wraps this for you:

// dashboard's main.single-spa.ts
import { singleSpaAngular, getSingleSpaExtraProviders } from 'single-spa-angular';
import { bootstrapApplication } from '@angular/platform-browser';
import { AppComponent } from './app/app.component';
import { appConfig } from './app/app.config';

const lifecycles = singleSpaAngular({
  bootstrapFunction: (singleSpaProps) =>
    bootstrapApplication(AppComponent, {
      ...appConfig,
      providers: [...appConfig.providers, getSingleSpaExtraProviders()],
    }),
  template: '<app-root />',
  Router: null, // let Angular's own router handle internal routes
  NgZone: Zone.current.fork({ name: 'dashboard' }) as any,
});

export const { bootstrap, mount, unmount } = lifecycles;

Notice the NgZone fork. This is the detail that separates a demo from a production setup — more on it below.

Sharing code with Module Federation (Native Federation for Angular)

For Angular apps built with the modern esbuild-based builder, @angular-architects/native-federation is the current standard — it replaced raw Webpack Module Federation config for teams on Angular's default build pipeline.

Remote (exposing a shared library):

// federation.config.js (remote: shared-ui)
module.exports = withNativeFederation({
  name: 'shared-ui',
  exposes: {
    './NotificationBell': './src/app/notification-bell.component.ts',
  },
  shared: {
    ...shareAll({
      singleton: true,
      strictVersion: false,
      requiredVersion: 'auto',
    }),
  },
});

Host (consuming it):

// federation.config.js (host: dashboard)
module.exports = withNativeFederation({
  shared: {
    ...shareAll({ singleton: true, strictVersion: false, requiredVersion: 'auto' }),
  },
});

// lazy-loading the remote component in a route
{
  path: 'notifications',
  loadComponent: () =>
    loadRemoteModule({
      remoteName: 'shared-ui',
      exposedModule: './NotificationBell',
    }).then((m) => m.NotificationBellComponent),
}

Because NotificationBellComponent is a standalone component, there's no NgModule ceremony on either side — this is one of the concrete reasons Angular 20+'s standalone-first posture matters for micro frontends specifically: fewer surfaces where two apps' module graphs can conflict.

Change detection implications — the part most tutorials skip

This is where micro frontends stop being a routing problem and become an Angular internals problem.

Zone.js collisions. By default, every Angular app monkey-patches the same global async APIs (setTimeout, addEventListener, Promise, XHR) through Zone.js. Load two independently-bootstrapped Angular apps on the same page without isolating their zones, and you get one of two failure modes: change detection storms (one app's async event triggers CD in both apps) or, worse, silent CD skips where updates in app B never render because zone context got lost crossing into app A's execution. The Zone.current.fork() call above isn't boilerplate — it's what keeps each MFE's change detection cycle scoped to itself.

Zoneless changes the calculus. Angular 18+'s zoneless change detection (stabilized further in 20) sidesteps the zone-collision problem entirely for apps that adopt it, because there's no shared monkey-patched global state to collide over — each app's signals and ChangeDetectorRef.markForCheck() calls are self-contained. If you're architecting a new micro frontend system today, defaulting every MFE to zoneless is one of the highest-leverage decisions you can make, precisely because it removes a whole category of cross-app bugs before they exist.

Singleton services aren't singletons anymore. providedIn: 'root' means root of that app's injector tree. Two federated apps each get their own instance of what looks like a shared service — including shared state services, auth token stores, and RxJS BehaviorSubject-based stores. If Dashboard and Billing both import an "auth state service" via Module Federation but each ends up with its own instance, they'll silently drift out of sync. The fix is either: promote true cross-cutting state to the shell and pass it down via custom events / a shared event bus, or explicitly share the service instance through Module Federation's shared config with singleton: true and verify at runtime that both apps resolved the same instance (log the object identity in dev, don't just assume the config worked).

Performance considerations

Duplicate bundle weight is the default failure mode, not an edge case. Without careful shared config, every MFE ships its own copy of Angular core, RxJS, and any common UI library — multiplying total payload by the number of MFEs on the page. shareAll({ singleton: true }) mitigates this but only for packages that are actually declared shared and version-compatible; a silent version mismatch causes federation to fall back to bundling a second copy, and that fallback fails quietly unless you're watching bundle analyzer output.
Waterfall loading across remotes. A host loading a remote that itself loads another remote creates a request waterfall invisible in local dev (everything's on localhost, latency is near zero) but very visible in production over real network conditions. Model this with WebPageTest or Chrome DevTools network throttling before shipping, not after a complaint ticket.
Version drift is a runtime bug, not a build error. Module Federation resolves shared dependency versions at runtime. Two teams shipping independently can produce a combination that was never tested together, and it'll only surface as a production error, not a build failure. This is the single biggest argument for contract testing between MFEs, not just unit tests within each one.

Common anti-patterns

Micro frontends that share a database-level of coupling in the UI layer — if Billing can't render without deep knowledge of Dashboard's internal component state, you've built a distributed monolith with extra deployment steps, not an independent system.
No shared design system, ad hoc CSS per MFE — leads to visual drift and specificity wars when MFEs are composed on the same page.
Treating Module Federation as a dependency injection replacement — it's a code-loading mechanism, not an architecture. It won't stop teams from building tightly coupled contracts unless you deliberately design against it.

Interview questions this topic tends to produce

How does Angular's Zone.js cause conflicts when multiple Angular apps run on the same page, and how would you isolate them?
Walk through what happens if two federated remotes declare incompatible versions of a shared singleton service.
Single-SPA vs Module Federation — when would you use one without the other?
How does moving to zoneless change detection affect micro frontend architecture decisions?
What's your strategy for testing integration between independently-deployed MFEs before they reach production?

Challenge exercise

Take a small Angular app with two standalone feature routes. Split it into a shell (Single-SPA) plus one Module Federation remote exposing a shared component with its own BehaviorSubject-backed state service. Verify — with actual console logging of instance identity, not assumption — whether the shell and the remote end up with one shared instance of that service or two. Then fix it so they share one, and write down exactly which config line made the difference.

Angular Signals in 2026: From Fundamentals to Architect-Level Patterns

Amanulla Khan — Sat, 11 Jul 2026 18:38:49 +0000

Angular used to be the framework you apologized for. Too much boilerplate, too much Zone.js magic, too much RxJS ceremony for a checkbox. Somewhere between v16 and v22, that changed. Signals are no longer "a new primitive to learn" — as of Angular 22 (June 2026), OnPush is the default change detection strategy, zoneless is the default for new apps, and Signal Forms and the Resource API are stable. Angular is now, by design, a signal-first framework.

This article covers the full arc: what signals are, how they work internally, how they change your architecture and performance story, how they compare to RxJS, and how to actually migrate a real codebase — plus the interview questions you'll get asked about all of it.

1. The fundamentals

A signal is a wrapper around a value that knows who's reading it.

import { signal, computed, effect } from '@angular/core';

const count = signal(0);          // writable signal
const doubled = computed(() => count() * 2); // derived, read-only, memoized

effect(() => {
  console.log(`count is now ${count()}`); // reruns when count changes
});

count.set(5);
count.update(v => v + 1);

Three primitives, three jobs:

signal() — holds state, read by calling it as a function, written via .set() / .update().
computed() — derives state. Lazy and memoized: it only recalculates when a dependency actually changed and someone reads it.
effect() — runs side effects (logging, syncing to localStorage, imperative DOM work) in response to signal changes. Not for driving template state — if you're setting another signal inside an effect to keep it "in sync," you probably wanted computed() or linkedSignal().

Angular 20 graduated all of these — plus signal-based input(), model(), and signal queries (viewChild, contentChild) — to stable. If you're on 20+, this is no longer "the new way," it's the way for new components.

@Component({ selector: 'app-user-card', standalone: true, template: `...` })
export class UserCardComponent {
  userId = input.required<string>();       // signal-based @Input
  isActive = model(false);                 // two-way bindable signal
  header = viewChild<ElementRef>('header'); // signal-based @ViewChild
}

2. How signals actually work (the internals interviewers ask about)

Signals implement a push-pull reactive model, and this distinction is the single most-tested concept in interviews:

Push: when a writable signal changes, it immediately (synchronously) notifies its direct consumers that they're "dirty." This is cheap — it's just a flag flip, not a recomputation.
Pull: the actual recomputation only happens lazily, when something reads the dirty signal — inside a computed() or during change detection when a template reads it.

This is why signals are glitch-free. In a naive push-based system, if computed C depends on both A and B, and you update A then B in the same tick, C might recompute twice and briefly observe an inconsistent intermediate state. Angular's dependency graph batches this: C is marked dirty once, and only recomputes once, on next read, with both updates applied.

Under the hood, each signal maintains a version counter. A computed() caches its last value and the versions of the signals it read last time. On read, it compares versions; if nothing upstream changed, it returns the cached value without re-executing the function — that's the memoization.

Dependency tracking is automatic and dynamic. There's no subscribe/unsubscribe. computed() and effect() track whatever signals were actually read during their last execution — so a conditional read (isAdmin() ? adminData() : userData()) only creates a dependency on the branch that actually executed. Change the condition, and the dependency set changes on the next run. This is structurally similar to Vue's reactivity system and SolidJS, and it's a fair comparison to bring up in an interview.

3. Change detection implications (this is the part senior candidates get wrong)

Pre-signals Angular used Zone.js to monkey-patch async APIs (setTimeout, addEventListener, promises) so it could guess something might have changed and run change detection on the whole component tree from the root. It works, but it's a blunt instrument — you get checks you don't need, and debugging "why did CD run" is miserable.

Signals flip this to explicit, targeted notification. A component reading a signal in its template gets automatically marked for a targeted check when that signal changes — no zone patching, no tree-wide guessing.

As of Angular 22, OnPush is the default changeDetection strategy for new components (the old "Default" strategy is renamed Eager and deprecated). Combined with zoneless (stable default since Angular 21), the practical effect is:

No Zone.js in your bundle (smaller payload, faster startup).
Change detection runs only for components whose signals actually changed, not the whole tree.
markForCheck() calls scattered through legacy code become mostly unnecessary — signals do it for you.
Non-signal mutations (mutating a plain array/object field that CD can't observe) silently stop working correctly under zoneless. This is the #1 zoneless migration bug — reaching into this.items.push(x) on a plain field instead of this.items.update(arr => [...arr, x]).

Interview question you should be able to answer cold: "Why does OnPush + signals outperform Zone.js-based default CD, and what's the one thing that breaks silently when you go zoneless?" Answer: targeted vs. tree-wide checks, and the answer to the second half is exactly the mutation issue above.

4. `linkedSignal` and `resource()` — the pieces that make signals a full state system

Two APIs turn signals from "a better @Input" into an actual state-management layer.

linkedSignal (stable since Angular 19) is a writable signal that resets itself when a source signal changes — the classic "selected item resets when the list changes" problem, without an effect() fighting your computed():

const items = signal(['a', 'b', 'c']);
const selected = linkedSignal(() => items()[0]); // resets to items()[0] whenever items() changes
selected.set('b'); // but user can still override it locally until items() changes again

resource() / httpResource() (stable in Angular 22) replace the "subscribe in ngOnInit, manage loading/error flags by hand" pattern with a declarative async primitive:

userId = input.required<string>();

userResource = httpResource<User>(() => `/api/users/${this.userId()}`);
// userResource.value(), userResource.status(), userResource.error(), userResource.isLoading()

Change userId, and the resource automatically re-fetches — no manual switchMap, no subscription teardown. As of Angular 21.2, snapshot() lets you derive a new resource from an existing one (e.g., a filtered/paginated view) without touching the original fetch logic — genuinely useful for enterprise dashboards with shared base data and multiple derived views.

5. Signals vs. RxJS — pick the right tool, not a religion

	Signals	RxJS
Best for	Synchronous UI state, derived values, template bindings	Streams over time: websockets, typeahead debounce, complex event composition
Mental model	Pull-based, glitch-free, always has a current value	Push-based, operators, may never emit
Boilerplate	Minimal — no subscribe/unsubscribe	Higher — operators, `takeUntilDestroyed`, memory-leak discipline
Composability	Growing (`linkedSignal`, `resource`) but narrower	Extremely rich (60+ operators)
Angular's stance (2026)	Default for component state	Still first-class for genuine async streams

The Angular team has been explicit: RxJS isn't going away. toSignal() / toObservable() interop exists precisely because you'll keep both in the same codebase — RxJS for a websocket-driven live feed, signals for the UI state that renders it. Treat "should I use signals or RxJS" the way you'd treat "should I use a Map or an array" — depends on the shape of the problem, not on which one is newer.

6. Migrating a real codebase (NgModules + RxJS → Signals)

Don't do a big-bang rewrite. The Angular team's own guidance, and what holds up in practice on large enterprise apps:

Upgrade to a supported version first. Combining a multi-version jump with a signals migration is the most common way these efforts stall out — get current, then modernize.
Convert leaf components first. Presentational components with @Input()/@Output() are low-risk: swap to input()/output(), verify, move up the tree.
Replace BehaviorSubject-as-state with signal(). If a BehaviorSubject exists purely to hold "current value UI reads," it's a signal in disguise.
Keep genuine streams as Observables, bridge with toSignal() at the template boundary.
Turn on OnPush explicitly before you touch signals, so you isolate "did this break because of CD strategy" from "did this break because of signals."
Zoneless last. It's the biggest behavioral change (silent mutation bugs) — do it once signals are already load-bearing in the app.

7. Enterprise example: a filtered order dashboard

@Component({
  selector: 'app-order-dashboard',
  standalone: true,
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `
    <input [ngModel]="statusFilter()" (ngModelChange)="statusFilter.set($event)" />
    @if (ordersResource.isLoading()) { <app-spinner /> }
    @for (order of filteredOrders(); track order.id) {
      <app-order-row [order]="order" />
    }
  `,
})
export class OrderDashboardComponent {
  customerId = input.required<string>();
  statusFilter = signal<'all' | 'pending' | 'shipped'>('all');

  ordersResource = httpResource<Order[]>(
    () => `/api/customers/${this.customerId()}/orders`
  );

  filteredOrders = computed(() => {
    const orders = this.ordersResource.value() ?? [];
    const status = this.statusFilter();
    return status === 'all' ? orders : orders.filter(o => o.status === status);
  });

  constructor() {
    effect(() => {
      // side effect only — analytics, not state
      analytics.track('dashboard_filtered', { status: this.statusFilter() });
    });
  }
}

Notice what's absent: no ngOnInit subscription, no loading/error boolean fields, no manual unsubscribe, no markForCheck(). Changing customerId() re-fetches automatically; changing statusFilter() re-filters automatically; both are independently cached and only recompute what actually needs it.

8. Common anti-patterns

Effects that write signals to "sync" state. If effect() exists only to call .set() on another signal, use computed() (or linkedSignal() if it needs local override capability) instead.
Reading a signal outside a reactive context and expecting reactivity. Calling count() in a regular method gives you a snapshot, not a subscription — reactivity only happens inside computed, effect, or a template.
Mutating instead of replacing (array.push() vs .update(a => [...a, x])) — silently breaks under zoneless/OnPush since the reference never changes.
Overusing effect() for cross-component communication instead of a shared injectable signal/service — reintroduces the debugging pain signals were meant to remove.

9. Interview questions to be ready for

Explain the push-pull model and why it makes signals glitch-free.
What's the practical difference between computed() and effect(), and when would using one instead of the other cause a bug?
Why does OnPush change detection pair naturally with signals, and what breaks when you combine plain-object mutation with zoneless CD?
How does dynamic dependency tracking work, and what happens to a computed's dependency list when a conditional branch changes?
When would you still reach for RxJS over signals in a signals-first Angular 22 app?
What does linkedSignal solve that a plain computed() can't?

10. Challenge exercise

Build a typeahead search component using httpResource() and linkedSignal(): a signal<string>() for the raw query, a computed() or linkedSignal() for a debounced/trimmed version (hint: you'll actually want RxJS's debounceTime here via toSignal(toObservable(query).pipe(debounceTime(300))) — a good exercise in knowing exactly where the signals/RxJS boundary should sit), and a resource() that re-fetches on the debounced value. Add a linkedSignal for "selected result" that resets whenever the result list changes.

Closing thought

Signals aren't a syntax swap for @Input() — they're Angular's answer to "how do we know exactly what changed, without guessing." That answer now shapes change detection defaults, forms, async data fetching, and DI. If you're prepping for a senior/architect role, the framework-trivia questions ("what's the syntax for computed") are table stakes; the questions that actually separate candidates are about the reactive graph — push vs. pull, dependency tracking, and where the signals/RxJS boundary should sit in a real system.