Top 30 Advanced Vue, Angular & Svelte Interview Questions and Answers

30 questions. Pick an answer, or open “Show the answer” to read it.

Answers are graded in your browser. Nothing is saved, and no XP or streak is earned here. The app keeps score.

1. Question 1 of 30

   Why does Vue's architectural philosophy make it the better choice for gradually modernizing a ten-year-old monolith one module per quarter?

   • aVue enforces strict TypeScript contracts out of the box, ensuring all teams follow identical conventions during migration.
   • bVue's progressive nature allows incremental adoption via the Composition API without requiring a full rewrite.
   • cAngular's two-way binding is incompatible with legacy state management patterns found in older codebases.
   • dAngular's lightweight runtime is designed specifically for partial integration into existing monoliths.
   Show the answer

   Answer: b · Vue's progressive nature allows incremental adoption via the Composition API without requiring a full rewrite.

   The card describes Vue as progressive and ideal for incremental adoption without full rewrites, using the Composition API for modular development. Distractor C incorrectly attributes Angular's built-in standardization to Vue, when in fact Vue's flexibility requires stronger platform discipline to prevent fragmentation.

   Read the full bite: How would Angular vs Vue philosophies influence your large-scale architecture choice?

2. Question 2 of 30

   When building a no-code canvas where users assemble layouts from hundreds of possible components at runtime, what is a concrete downside of Svelte's compile-time model versus Vue or Angular?

   • aSvelte always yields smaller bundles than Vue or Angular for highly dynamic apps because it eliminates the need for any runtime overhead.
   • bSvelte can lazily load dynamic components via string mapping at runtime without losing compile-time tree-shaking benefits.
   • cSvelte makes dynamic component resolution impossible because it compiles to imperative DOM operations without retaining runtime metadata.
   • dSvelte must eagerly import all possible dynamic targets, sacrificing tree-shaking and reintroducing runtime overhead through escape hatches like svelte:component.
   Show the answer

   Answer: d · Svelte must eagerly import all possible dynamic targets, sacrificing tree-shaking and reintroducing runtime overhead through escape hatches like svelte:component.

   The correct answer notes that Svelte requires eager imports and runtime escape hatches for open-ended dynamic sets, which reintroduces overhead and sacrifices tree-shaking. Distractor A is tempting because Svelte does compile to imperative DOM operations, but dynamic components are still possible via compiler-aware patterns rather than impossible.

   Read the full bite: Svelte compiler downsides vs Vue and Angular runtime

3. Question 3 of 30

   When implementing route-level lazy loading for an NgModule, which combination ensures the CLI emits a separate chunk without manual build configuration?

   • aThe feature uses loadChildren with a dynamic import and a custom Webpack entry point
   • bThe feature uses loadChildren with a dynamic import and is removed from AppModule imports
   • cThe feature uses loadComponent with a dynamic import while remaining in AppModule imports
   • dThe feature uses a string-based loadChildren path and is declared in AppModule declarations
   Show the answer

   Answer: b · The feature uses loadChildren with a dynamic import and is removed from AppModule imports

   The CLI automatically splits a chunk when it detects a dynamic import in loadChildren and the module is absent from AppModule's static dependency graph. Manual Webpack entry points are a red flag because Angular abstracts the build tool, and keeping an eager import in AppModule forces the feature into the main bundle.

   Read the full bite: How would you implement lazy loading for an Angular feature module?

4. Question 4 of 30

   In a single Vite Library Mode build producing ESM and UMD outputs, which setup correctly externalizes Vue and maps it to window.Vue in the UMD bundle?

   • abuild.rollupOptions.external includes vue and build.lib.formats includes umd, but globals is omitted since ESM does not need it
   • bbuild.rollupOptions.external includes vue and output.globals maps vue to Vue, with formats set to es and umd
   • cTwo vite.config.js files are used, one with format es and one with format umd, both excluding vue from the bundle
   • dbuild.lib.name is set to Vue and build.rollupOptions.external includes vue, omitting output.globals
   Show the answer

   Answer: b · build.rollupOptions.external includes vue and output.globals maps vue to Vue, with formats set to es and umd

   rollupOptions.external keeps Vue out of the bundle while output.globals tells the UMD build to use window.Vue at runtime. The most tempting distractor omits globals because ESM does not need them, but without that mapping the UMD output will throw a runtime error trying to resolve vue as a module.

   Read the full bite: How do you configure Vite Library Mode for ESM and UMD outputs?

5. Question 5 of 30

   You have a product listing page that updates daily. Should you prerender it or SSR it? What's the main trade-off?

   • aPrerender once per day on a cron schedule to balance freshness and speed
   • bSSR for always-fresh data, but accept per-request latency and server load
   • cPrerender for instant load, but accept stale data until rebuild
   • dUse prerender with client-side polling to fetch updates after page load
   Show the answer

   Answer: a · Prerender once per day on a cron schedule to balance freshness and speed

   Daily-updated content fits a hybrid model: prerender on a cron (freshness every 24 hours) combined with instant static serve. Option C (prerender without schedule) risks stale data. Option B (pure SSR) is overkill and costly if the data doesn't change frequently. Option D adds complexity without solving the core need.

   Read the full bite: Prerendering vs SSR in SvelteKit: trade-offs?

6. Question 6 of 30

   In a reusable DataList component, what is the primary architectural benefit of using scoped slots instead of having the parent manage the iteration?

   • aIt allows the child to own data fetching, filtering, and iteration while the parent controls only the visual template for each row.
   • bIt eliminates the need for the child to hold any state, since all data logic moves to the parent.
   • cIt lets the parent access the child's internal variables directly inside projected content without explicit prop passing.
   • dIt improves rendering performance by avoiding the creation of separate component instances for each row.
   Show the answer

   Answer: a · It allows the child to own data fetching, filtering, and iteration while the parent controls only the visual template for each row.

   Scoped slots preserve encapsulation by keeping data fetching and iteration inside the child while letting the parent determine markup. Option C is a common misconception because slot content uses lexical scope and cannot see child data unless the child explicitly exposes it through slot props or template context.

   Read the full bite: Implement a scoped slot pattern in a reusable DataList

7. Question 7 of 30

   When architecting a headless Toggle component, which approach correctly inverts control so the parent owns the markup?

   • aRendering only a scoped slot that passes on and toggle to the parent, which decides what DOM to emit
   • bAccepting theme, color, and layout props to customize a pre-rendered button inside the component
   • cWrapping the slot in a div and exposing CSS variables for the parent to style the wrapper
   • dEmitting toggle events upward and expecting the parent to implement its own state machine
   Show the answer

   Answer: a · Rendering only a scoped slot that passes on and toggle to the parent, which decides what DOM to emit

   A headless component must render no DOM of its own and expose state and actions through a scoped slot so the parent controls all markup. Option B is a red flag because config props like theme tightly couple logic to a specific visual implementation rather than truly inverting control.

   Read the full bite: Architect a headless Toggle with scoped slots

8. Question 8 of 30

   When a parent mutates a nested property of an object passed to a child component, how does Vue 3's behavior differ from Angular's OnPush strategy?

   • aVue 3 only detects the mutation if the object is wrapped with deep: true in a watcher, whereas Angular OnPush detects it during the next zone tick.
   • bBoth frameworks require immutable updates or manual diffing to propagate nested changes to child component templates.
   • cAngular Default detects the change through deep observation of input objects, behaving similarly to Vue 3 until switching to OnPush.
   • dVue 3 recursively tracks nested access with Proxies and updates dependents automatically, while Angular OnPush skips re-rendering because the input reference remains unchanged.
   Show the answer

   Answer: d · Vue 3 recursively tracks nested access with Proxies and updates dependents automatically, while Angular OnPush skips re-rendering because the input reference remains unchanged.

   Vue 3 uses Proxy-based reactivity to intercept and trigger updates for nested mutations automatically, while Angular OnPush only checks input references and skips re-rendering when they are unchanged. Option C is wrong because Angular Default never performs deep observation; it relies on zone.js-triggered digest cycles, so it does not behave like Vue 3.

   Read the full bite: How do Vue and Angular detect nested object mutations?

9. Question 9 of 30

   An OnPush child receives an array input and subscribes to an observable in ngOnInit. The parent mutates the array with push() and the observable emits. What happens to the view?

   • aOnly the emitted value renders because the subscription callback runs inside Angular's zone
   • bBoth the pushed item and the emitted value render because OnPush still detects asynchronous activity
   • cOnly the pushed item renders because input mutations always trigger OnPush
   • dNeither renders because the array reference did not change and the subscription omits markForCheck
   Show the answer

   Answer: d · Neither renders because the array reference did not change and the subscription omits markForCheck

   OnPush skips checks unless an input reference changes, a DOM event fires, or markForCheck is called, so both the mutated array and the unmarked subscription silently fail to update. The distractor suggesting asynchronous activity automatically triggers detection is wrong because manual subscriptions run outside the template's automatic signaling unless paired with markForCheck or the async pipe.

   Read the full bite: How does Angular OnPush change detection affect rendering?

10. Question 10 of 30

    A Vue modal inside a transformed ancestor uses position: fixed yet fails to fill the viewport. What explains why Teleport fixes this?

    • aIt promotes the modal's z-index above all ancestors without changing its physical DOM location.
    • bIt relocates the modal's markup to the body, escaping the ancestor's containing block and stacking context while keeping reactivity intact.
    • cIt removes wrapper divs to flatten the component tree and simplify the HTML structure.
    • dIt transfers the component instance and reactive scope to the target DOM node outside the Vue tree.
    Show the answer

    Answer: b · It relocates the modal's markup to the body, escaping the ancestor's containing block and stacking context while keeping reactivity intact.

    Teleport moves the markup to the body so the modal escapes the ancestor's transform-created containing block and stacking context, while its reactive state remains in the Vue tree. Distractor D is wrong because increasing z-index alone cannot escape a containing block, and Teleport explicitly changes the physical DOM location.

    Read the full bite: In Vue 3, what problem does Teleport solve?

11. Question 11 of 30

    Which approach correctly implements a custom *appDelay structural directive that defers template instantiation?

    • aInject TemplateRef and ViewContainerRef, schedule createEmbeddedView in setTimeout, and rely solely on viewContainer.clear() in ngOnDestroy for cleanup
    • bInject ElementRef and Renderer2, then use setTimeout to toggle the host element's visibility after the delay
    • cAccess the native DOM element through TemplateRef and append it to the view container's anchor after the delay
    • dInject TemplateRef and ViewContainerRef, use setTimeout to call createEmbeddedView with the template, and clear pending timeouts in ngOnDestroy
    Show the answer

    Answer: d · Inject TemplateRef and ViewContainerRef, use setTimeout to call createEmbeddedView with the template, and clear pending timeouts in ngOnDestroy

    Option D is correct because a structural directive uses TemplateRef as the unmounted template definition and ViewContainerRef to instantiate it after the delay, while ngOnDestroy must clear pending timeouts to prevent memory leaks. Option A is tempting because it uses the correct APIs, but relying only on viewContainer.clear() leaves dangling timeouts that can fire after destruction and attempt to create views in a destroyed container.

    Read the full bite: How would you create a custom *appDelay structural directive?

12. Question 12 of 30

    Which architectural trade-off does Svelte's compiler-based reactivity sacrifice for smaller bundle size?

    • aSvelte can't support two-way binding (v-model equivalents)
    • bSvelte can't handle dynamic property access that wasn't predictable at compile time
    • cSvelte requires all components to be pre-compiled; you can't use dynamic imports
    • dSvelte components have slower runtime performance than Vue
    Show the answer

    Answer: b · Svelte can't handle dynamic property access that wasn't predictable at compile time

    Svelte's compiler analyzes code statically to find reactive assignments. If code dynamically accesses properties (obj[key] where key is unknown), the compiler can't instrument it. Vue's runtime Proxies handle arbitrary access (Option B is the real limitation). Options B, C, D are false; Svelte supports dynamic imports, is actually fast, and supports two-way binding.

    Read the full bite: Compiler vs runtime reactivity: Svelte, Vue, Angular?

13. Question 13 of 30

    Which statement accurately compares lifecycle cleanup of reactive subscriptions in Vue 3's Composition API and Svelte?

    • aBoth frameworks require storing a subscription token in onMounted and calling unsubscribe in onUnmounted to avoid memory leaks.
    • bVue templates auto-subscribe to Observables like Angular's async pipe, while Svelte requires manual unsubscribe for any store used with the dollar prefix.
    • cSvelte's dollar-prefixed stores must be paired with onDestroy to prevent leaks, whereas Vue's computed properties automatically teardown external Observable subscriptions.
    • dVue's watchEffect automatically cleans up its effect on unmount, while Svelte's dollar-prefixed store syntax generates lifecycle-bound subscribe and unsubscribe calls at compile time.
    Show the answer

    Answer: d · Vue's watchEffect automatically cleans up its effect on unmount, while Svelte's dollar-prefixed store syntax generates lifecycle-bound subscribe and unsubscribe calls at compile time.

    Vue's watchEffect tracks dependencies and cleans up automatically on unmount, while Svelte's compiler auto-generates subscription management for dollar-prefixed stores. The first option is tempting because developers from Angular often assume Vue has template-level auto-subscription, but the Composition API does not provide this primitive.

    Read the full bite: Implement auto-cleanup reactive logic in Vue's Composition API and Svelte

14. Question 14 of 30

    You are choosing an encapsulation strategy for a design-system widget deployed on pages your team controls. What tradeoff makes Shadow DOM a worse default than build-time scoping?

    • aShadow DOM improves rendering performance by scoping style recalculation, making it preferable to build-time scoping even when the host page is trusted.
    • bBuild-time scoping offers the same encapsulation as Shadow DOM because hashed class names prevent both accidental collisions and deliberate host JavaScript mutation.
    • cShadow DOM makes external theming impossible, so build-time scoping is the only viable choice when the consuming team needs to customize tokens.
    • dShadow DOM blocks global theme inheritance and complicates SSR, whereas build-time scoping keeps the component in the global document for natural theming and trivial server rendering.
    Show the answer

    Answer: d · Shadow DOM blocks global theme inheritance and complicates SSR, whereas build-time scoping keeps the component in the global document for natural theming and trivial server rendering.

    Build-time scoping preserves the cascade and produces plain HTML that renders easily on the server, while Shadow DOM forces explicit theming contracts and client-side shadow root creation. Option B is wrong because hashed classes only stop accidental selector collisions; host JavaScript can still deliberately query and mutate internals.

    Read the full bite: Shadow DOM vs build-time scoping for third-party widgets

15. Question 15 of 30

    How does Vue's v-bind() CSS function in SFC style blocks make reactive values work with pseudo-selectors like :hover?

    • aIt interpolates the value directly into the stylesheet string during runtime rendering.
    • bIt dynamically rewrites the CSS text in the style tag whenever the reactive state changes.
    • cIt compiles the binding into a scoped CSS custom property and syncs that variable's value at runtime.
    • dIt applies the value as an inline style on the element, identical to a template :style binding.
    Show the answer

    Answer: c · It compiles the binding into a scoped CSS custom property and syncs that variable's value at runtime.

    Vue compiles v-bind() into a scoped CSS custom property so reactive values live in the stylesheet cascade, enabling pseudo-selectors and media queries. The inline-style distractor is wrong because inline styles bypass the cascade and cannot target pseudo-elements or responsive rules.

    Read the full bite: How does Vue's v-bind() CSS function work in style blocks?

16. Question 16 of 30

    How does using :global() in a Svelte component differ from linking an external stylesheet for the same global styles?

    • aExternal stylesheets are automatically scoped by Svelte unless wrapped in :global(), making them safer for isolated global overrides.
    • bBoth approaches preserve Svelte's component-level dead-code elimination and prevent specificity conflicts with other components.
    • c:global() moves the wrapped rules to the app's global CSS file at build time so they no longer appear in the component.
    • d:global() keeps the CSS co-located in the component but tells the compiler to omit the scoped hash for the wrapped selector, while an external stylesheet bypasses Svelte's dead-code elimination.
    Show the answer

    Answer: d · :global() keeps the CSS co-located in the component but tells the compiler to omit the scoped hash for the wrapped selector, while an external stylesheet bypasses Svelte's dead-code elimination.

    :global() tells the Svelte compiler to omit the scoped hash for the wrapped selector while keeping the rule co-located, whereas an external stylesheet bypasses dead-code elimination. Distractor B is wrong because :global() does not extract styles to a separate file; the CSS stays inside the component.

    Read the full bite: How do you bypass Svelte's scoped styles to target global elements?

17. Question 17 of 30

    Which approach correctly implements an AsyncValidatorFn that performs an HTTP username check while minimizing backend load and preventing race conditions?

    • aReturn an Observable that uses debounceTime and switchMap, letting Angular set PENDING and bind control.pending in the template
    • bSubscribe to the HTTP call inside the validator, call markAsPending on the control, and update a component property to show the loading state
    • cReturn the HTTP Observable directly without debounceTime so every keystroke triggers an immediate, cancelable request
    • dReturn a Promise from the HTTP call and manually set the control to PENDING with markAsPending until it resolves
    Show the answer

    Answer: a · Return an Observable that uses debounceTime and switchMap, letting Angular set PENDING and bind control.pending in the template

    Returning a debounced Observable with switchMap allows Angular to automatically manage the PENDING status, unsubscribe from prior in-flight requests when the value changes, and avoid memory leaks. Option B breaks cancellation by subscribing internally and wrongly manages state imperatively, while C uses an uncancelable Promise and manual pending, and D floods the backend by skipping debounce.

    Read the full bite: Implement an async Angular validator with HTTP and PENDING feedback

18. Question 18 of 30

    When building a dynamic Vue form where users can add, remove, and reorder rows, which pattern best preserves reactivity, component state, and clean validation logic?

    • aUse a flat reactive array with unique row IDs and bind :key to row.id, but replace entire rows via index assignment (e.g., items[i] = newRow) and embed validation rules inside each row object.
    • bUse a flat reactive array where each row has a unique id, bind :key to row.id, render each row in its own component, and keep validation rules in a separate schema keyed by field name.
    • cUse a flat reactive array without explicit IDs, bind :key to the array index, emit updates from row components, and maintain a separate validation schema keyed by field name.
    • dUse a flat reactive array with unique row IDs and bind :key to row.id, but handle all edits via v-model directly on the array in the parent and map validation errors to a parallel array aligned by index.
    Show the answer

    Answer: b · Use a flat reactive array where each row has a unique id, bind :key to row.id, render each row in its own component, and keep validation rules in a separate schema keyed by field name.

    Option B is correct because stable row IDs as :key let Vue track insertions and deletions accurately, row components encapsulate mutations and local state, and a separate schema keeps validation metadata out of the business model. Option A is tempting because it also uses unique IDs, but mutating the array by index breaks reactivity detection and embedding validation rules inside row data couples schema to state.

    Read the full bite: How do you structure components and state for a dynamic Vue form?

19. Question 19 of 30

    When building a multi-step Svelte wizard with stores, which approach best persists state across unmounted steps and enforces validation before navigation?

    • aUse a single store for all data and derive isValid for each step, but let each component automatically advance the wizard via reactive statements when its validity becomes true.
    • bMaintain separate writable stores per step to isolate concerns, merging them only during final submission validation.
    • cKeep step form data in local component variables and use a global writable store only for the active step index and final payload assembly.
    • dCentralize all wizard state in a single store keyed by step, compute validity via derived stores, and call an imperative validateStep guard before incrementing the active step index.
    Show the answer

    Answer: d · Centralize all wizard state in a single store keyed by step, compute validity via derived stores, and call an imperative validateStep guard before incrementing the active step index.

    A centralized store keyed by step ensures data survives unmounting, while derived validity and imperative guards keep progression declarative yet explicitly controlled. Option A is tempting because it uses a single store and derived state, but reactive auto-advance bypasses pre-navigation guards and can advance before async validation finishes.

    Read the full bite: How would you architect a multi-step Svelte wizard with Stores?

20. Question 20 of 30

    When a team uses Pinia to store and manually refetch API-fetched order lists, which server-state behavior are they forced to reinvent that Vue Query provides automatically?

    • aReactive synchronization of local UI themes across components
    • bSynchronous deterministic state access during server-side rendering
    • cRequest deduplication, stale-while-revalidate semantics, and background refetching
    • dModule composition and devtools integration for client-side stores
    Show the answer

    Answer: c · Request deduplication, stale-while-revalidate semantics, and background refetching

    Pinia has no built-in mechanism for deduplicating in-flight requests, handling stale-while-revalidate caching, or automatically refetching on window focus, all of which are core to Vue Query. Distractor A describes a client-state concern that Pinia already handles well, making it a tempting misdirection for those conflating the two state types.

    Read the full bite: Differentiate client state from server state and their tools

21. Question 21 of 30

    When the derived store's dependencies change while a fetch is still in-flight, what must the callback do to keep the utility race-safe?

    • aQueue the new fetch until the original one resolves to guarantee order and avoid duplicate requests
    • bReturn a cleanup function or use an AbortController to cancel the stale request and ignore its result
    • cLet the original promise resolve and overwrite the store so no network response is discarded
    • dInvoke the readable store's StartStopNotifier to teardown and recreate the subscription before starting the new fetch
    Show the answer

    Answer: b · Return a cleanup function or use an AbortController to cancel the stale request and ignore its result

    The derived callback must cancel or ignore stale requests—typically by returning a cleanup or using an AbortController—so that slower, older responses cannot overwrite fresher data. Simply letting the original promise resolve causes the exact stale-overwrite race bug the pattern is meant to prevent.

    Read the full bite: Build a reactive data-fetching utility with Svelte stores

22. Question 22 of 30

    Why might a dashboard with a required config object use a Resolve guard instead of fetching in ngOnInit?

    • aResolve is primarily a best practice for cleaner separation of concerns without changing routing behavior
    • bResolve allows the dashboard to render immediately while the config loads asynchronously in the background
    • cResolve runs inside the dashboard's ngOnInit to keep data fetching logic close to the component
    • dResolve blocks navigation until the config loads, preventing the dashboard shell from rendering if the fetch fails
    Show the answer

    Answer: d · Resolve blocks navigation until the config loads, preventing the dashboard shell from rendering if the fetch fails

    Resolve guards block route activation until the observable emits, guaranteeing the component mounts with data present and enabling pre-render redirects. Option B incorrectly describes ngOnInit behavior, which causes visible layout shifts and leaves users on a broken page when the fetch fails.

    Read the full bite: What is the purpose of an Angular Resolve guard vs ngOnInit?

23. Question 23 of 30

    Which accurately describes a trade-off when choosing SvelteKit's filesystem routing over Vue Router's explicit configuration?

    • aSvelteKit separates routing configuration from data fetching, making SSR boundaries clearer than Vue Router
    • bSvelteKit removes route registration boilerplate but makes global navigation harder to audit because route logic is distributed across directories
    • cSvelteKit prevents broken deep links because URLs are generated at runtime rather than tied to folder names
    • dSvelteKit eliminates all configuration by deriving routes automatically from the folder tree
    Show the answer

    Answer: b · SvelteKit removes route registration boilerplate but makes global navigation harder to audit because route logic is distributed across directories

    SvelteKit's filesystem routing removes registration boilerplate but scatters routing knowledge across directories, complicating global audits compared to a centralized Vue Router config. The most tempting distractor claims SvelteKit eliminates all configuration, yet the directory structure is itself implicit configuration that tightly couples URLs to folder names.

    Read the full bite: Contrast SvelteKit file-system routing with Vue/Angular router configs

24. Question 24 of 30

    Which strategy correctly implements router-level scroll management that preserves native back/forward position restoration while starting new navigations at the top?

    • aProvide a centralized scrollBehavior function that returns savedPosition for back/forward navigations, top: 0 for new visits, and can delay via a Promise during transitions.
    • bRely on CSS scroll-padding for fixed headers and avoid router scroll hooks, as browsers natively restore scroll on history traversal.
    • cAlways return { top: 0 } from scrollBehavior regardless of navigation type to ensure users consistently start at the top of every page.
    • dHandle scrolling inside each route component by calling window.scrollTo in onMounted, keeping scroll logic colocated with the page.
    Show the answer

    Answer: a · Provide a centralized scrollBehavior function that returns savedPosition for back/forward navigations, top: 0 for new visits, and can delay via a Promise during transitions.

    A centralized scrollBehavior hook is the correct place to conditionally return savedPosition on popstate or top: 0 otherwise, and returning a Promise prevents scroll from racing page transitions. Option D fragments logic and breaks native history restoration, while C destroys the user's history position on back/forward and D ignores that scrollBehavior is needed for deliberate control beyond native behavior.

    Read the full bite: How do you manage router scroll behavior and history position restoration?

25. Question 25 of 30

    What is the main architectural risk when using module-scoped reactive state in a Vue composable?

    • aEach consumer receives a deep clone of the state, breaking reactivity across components
    • bLifecycle hooks like onUnmounted may behave unexpectedly when the last consumer unmounts
    • cThe composable can only be called safely once per application
    • dThe state resets to its initial value whenever any consumer re-renders
    Show the answer

    Answer: b · Lifecycle hooks like onUnmounted may behave unexpectedly when the last consumer unmounts

    Module-scoped state persists beyond any single component, so lifecycle hooks tied to that scope do not map cleanly to individual component lifetimes. Distractor C is wrong because consumers share the exact same reactive reference, not clones, which is precisely why mutations propagate everywhere.

    Read the full bite: How would you design useCounter to support shared or independent state?

26. Question 26 of 30

    Why provide a stateful service in a reusable component's providers array when multiple instances must coexist independently?

    • aIt ensures all instances share a single state object synchronized through the root injector.
    • bIt scopes the service to the lazy-loaded module containing the component.
    • cIt improves app performance by reducing the total number of service instances created across the application.
    • dIt creates one instance per component subtree, isolating state and enabling cleanup on destroy.
    Show the answer

    Answer: d · It creates one instance per component subtree, isolating state and enabling cleanup on destroy.

    Component providers create one service instance per subtree, isolating mutable state and allowing garbage collection when the component is destroyed. The performance rationale is a common red flag because the primary goal is state isolation, not reducing instance count or saving memory.

    Read the full bite: When would you provide an Angular service at the component level?

27. Question 27 of 30

    Which approach correctly implements a Svelte action that keeps CSS custom properties on a node in sync with a reactive parameter object?

    • aRe-run the action on each change by calling it from a reactive statement in the component
    • bReturn an update method that swaps properties via node.style.removeProperty and node.style.setProperty, plus a destroy method that clears them
    • cApply styles once during mount, because Svelte automatically re-invokes the action when the passed arguments change
    • dUse $derived or $effect inside the action to track parameter changes and mutate the node's style
    Show the answer

    Answer: b · Return an update method that swaps properties via node.style.removeProperty and node.style.setProperty, plus a destroy method that clears them

    A Svelte action attaches once on mount and uses the returned update method to react to new parameters without destroying the node, while destroy handles teardown. Option A is wrong because trying to re-run the action from a reactive statement breaks its long-lived lifecycle and remounts the attachment instead of updating it.

    Read the full bite: Explain Svelte Action update and provide a reactive CSS example

28. Question 28 of 30

    A third-party library emits 100 mousemove events per second. By default, each triggers Angular change detection, freezing the app. Which pattern best fixes this?

    • aWrap the library's event listeners in NgZone.runOutsideAngular()
    • bDisable zone.js entirely in angular.json
    • cUse ChangeDetectorRef.detach() and manually call detect() in a RAF loop
    • dUse OnPush change detection strategy on the component
    Show the answer

    Answer: a · Wrap the library's event listeners in NgZone.runOutsideAngular()

    Option A directly prevents the library's events from entering Angular's zone, so they don't trigger detection. OnPush (D) helps but doesn't solve the root cause (zone.js still runs). Disabling zone.js (B) breaks Angular's normal async tracking. RAF loop (C) is premature optimization and harder to maintain than scoped runOutsideAngular.

    Read the full bite: Zone.js and change detection optimization in Angular?

29. Question 29 of 30

    You keep a normalized global writable store fed by a WebSocket. A component only needs the alerts slice. Which approach prevents it from re-rendering when the quotes slice updates?

    • aExport derived(globalStore, s => s.alerts) and subscribe to that
    • bReturn a deep-cloned copy of s.alerts from the derived callback
    • cSubscribe to the global store and filter updates in a reactive statement
    • dPass the global store via Context and read alerts in the component
    Show the answer

    Answer: a · Export derived(globalStore, s => s.alerts) and subscribe to that

    A derived store notifies subscribers only when its returned value changes by reference inequality, so returning the stable s.alerts reference prevents re-renders when unrelated slices mutate. Filtering in a reactive statement still runs on every parent emission, and deep cloning breaks the reference stability that Svelte uses to skip updates.

    Read the full bite: How do you architect Svelte stores to minimize WebSocket re-renders?

30. Question 30 of 30

    You profile a suite of 200 component specs that each import a SharedModule with 50 declarations; the suite takes over five minutes. Which action most directly reduces TestBed recompilation overhead?

    • aMigrate from Karma to Vitest with jsdom to eliminate browser launch time
    • bAdd NO_ERRORS_SCHEMA to every TestBed.configureTestingModule call to suppress template errors
    • cReplace the SharedModule import with targeted component imports and stubs, and move global providers into a providersFile
    • dDisable automatic change detection in all specs to reduce DOM updates during tests
    Show the answer

    Answer: c · Replace the SharedModule import with targeted component imports and stubs, and move global providers into a providersFile

    Importing only the declarations a spec actually needs and centralizing providers prevents TestBed from repeatedly recompiling the entire SharedModule surface. Migrating to Vitest is valuable for runner overhead but does not reduce TestBed compilation cost, while NO_ERRORS_SCHEMA merely hides missing declarations without improving speed.

    Read the full bite: How would you diagnose and optimize slow Angular component tests?