Single-SPA Interview Questions

Single-SPA Interview Overview

single-spa is a microfrontend orchestrator for the browser: a root config registers applications, maps routes to apps, and calls lifecycle functions (bootstrap, mount, unmount) as users navigate. Each microfrontend can use React, Vue, or Angular independently while sharing one URL and one page shell.

Interviews compare single-spa with Module Federation and iframes, ask about parcels vs applications, layout engines, and how to share dependencies without runtime conflicts. Understanding lifecycle timing and routing integration separates strong architecture answers.

Single-SPA Interview Cheatsheet

Quick answers you can expand in a real interview.

15 Single-SPA Interview Questions with Answers

Use the short version first, then offer trade-offs if the interviewer wants depth.

1. What problem does single-spa solve?

single-spa lets multiple independently deployed frontend apps coexist in one browser tab with coordinated routing and lifecycle. Teams choose their framework and release cadence while users see one cohesive site. The root config decides which microfrontend is active for a given URL.

2. Describe the single-spa application lifecycle.

Each app exports bootstrap, mount, and unmount (and optional unload) async functions. bootstrap runs once before first mount—setup globals or fetch config. mount renders into a DOM element when the route matches activeWhen. unmount cleans up when navigating away—unsubscribe listeners and destroy frameworks to prevent leaks.

3. What is the root config responsible for?

The root config imports registerApplication for each microfrontend with name, loading function (SystemJS import or dynamic import), and activeWhen. Calling start() begins routing listeners. It may use layout engines (single-spa-layout) to define DOM slots—header, sidebar, main—for Parcels and applications.

4. What is activeWhen and how is it used?

activeWhen determines if an application should mount—commonly location.pathname.startsWith("/dashboard") or a path prefix array. Multiple apps can be active if predicates overlap intentionally (e.g., persistent header app). Misconfigured activeWhen causes apps not to mount or fail to unmount.

5. What is the difference between an application and a parcel?

Applications are route-driven: single-spa mounts them when activeWhen matches. Parcels are manually mounted components—mountRootParcel or parcel config—usable inside any app for cross-framework widgets like a React cart in a Vue page. Parcels share lifecycle functions but are not tied to URL alone.

6. How does single-spa compare to Module Federation?

single-spa focuses on runtime orchestration and lifecycle across frameworks; loading is often via SystemJS/import maps or bundler integration. Module Federation focuses on sharing JS modules between webpack builds. They can complement each other—single-spa routes apps that load federated remotes internally.

7. How do you share dependencies between microfrontends in single-spa?

Use import maps or webpack externals to load one shared React/Vue instance from a CDN or shell. Duplicate frameworks break hooks and inflate bundles. Organizations publish a shared dependencies policy and version alignment in the root package or import map JSON.

8. What is single-spa-layout?

single-spa-layout defines an HTML-like route tree specifying which applications and parcels render in which DOM nodes—e.g., nav always mounted, content swaps by route. It reduces imperative DOM juggling in root config and documents shell structure declaratively.

9. How do you integrate React with single-spa?

Use single-spa-react helper: singleSpaReact({ React, ReactDOM, rootComponent, errorBoundary }) returns lifecycle functions. rootComponent receives single-spa props like name and mountParcel. Render with createRoot in mount and unmount at root.unmount. Wrap router basename to match activeWhen prefix.

10. What routing pitfalls appear in microfrontend architectures?

Each app may ship its own router—coordinate base paths so nested routes do not collide. Only one router should own browser history or use hash routing in legacy cases. The shell typically owns top-level paths; child apps use memory or prefixed browser routers with agreed URL contract.

11. How do you handle global state across microfrontends?

Prefer lightweight cross-app communication: custom events, shared RxJS observables, or a minimal global store mounted once in the shell. Avoid tight coupling; pass props via mountParcel or URL/query for infrequent data. Backend remains source of truth for durable shared state.

12. What is import map overhead in single-spa deployments?

Import maps tell the browser where to fetch bare specifiers like react and app modules. They enable independent deploy URLs per microfrontend. Operations must keep map URLs current after deploys and handle cache busting. Incorrect maps cause load failures for entire apps.

13. How do you test microfrontends locally?

Run root config and each app on separate ports with import map overrides pointing to localhost. Tools like single-spa-inspector debug active apps. Integration tests deploy all apps to a staging environment. Contract-test activeWhen paths and exposed parcel APIs between teams.

14. What are common performance considerations?

Lazy-load inactive apps via dynamic import in the loading function. Unmount must destroy frameworks to free memory on long sessions. Avoid loading all microfrontends upfront. Prefetch likely next routes sparingly. Monitor Time to Interactive when switching apps on slow networks.

15. When would you choose iframes over single-spa?

Iframes provide strong isolation for untrusted third-party code or legacy apps you cannot integrate. They simplify CSS/JS conflicts but complicate UX—routing, analytics, and modals spanning apps. single-spa suits trusted internal teams wanting unified DOM and shared design system integration.

Common Mistakes

• Forgetting to unmount React/Vue roots and leaking memory on navigation.
• Letting each microfrontend bundle its own copy of React.
• Overlapping activeWhen rules that mount conflicting apps on the same DOM node.
• No agreed URL contract between shell router and child app routers.

Key Takeaways

• single-spa orchestrates lifecycle and routing across independent apps.
• Applications are route-driven; parcels mount manually for shared widgets.
• Root config + import maps wire deployments without monolithic builds.
• Shared dependency strategy is as important as routing configuration.