Top 30 Reactivity 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

   When a reactive variable changes in Svelte, how is the update triggered differently than in Vue 3's runtime Proxy system?

   • aBy compiler transforms that turn assignments into explicit update calls
   • bThrough ES6 Proxies that intercept property mutations at runtime
   • cVia Object.defineProperty on every reactive property during mount
   • dThrough two-way binding that automatically syncs the variable and DOM
   Show the answer

   Answer: a · By compiler transforms that turn assignments into explicit update calls

   Svelte resolves dependencies at build time by transforming assignments into explicit update logic in the compiled output, so no runtime tracker is needed. Option B is tempting because Vue 3 uses runtime Proxies, but Svelte does not use them at all.

   Read the full bite: Compare and contrast Vue 3 and Svelte reactivity systems

2. Question 2 of 30

   When reactive state changes in a Svelte component, how does the compiled application update the browser DOM?

   • aIt creates a lightweight virtual DOM tree and diffs it against the previous render to determine patches.
   • bIt re-evaluates the template through a compiler-generated diffing algorithm to patch the real DOM.
   • cIt performs dirty checking across component bindings and reconciles mismatches against the live DOM.
   • dIt executes pre-generated imperative statements that directly mutate the affected DOM nodes.
   Show the answer

   Answer: d · It executes pre-generated imperative statements that directly mutate the affected DOM nodes.

   Svelte compiles components into imperative vanilla JavaScript that retains direct references to DOM nodes and executes precise update statements when state changes, so no intermediate tree is ever created. The distractor suggesting a hidden virtual DOM is wrong because the compiler deliberately avoids emitting any diffing or reconciliation runtime, generating direct DOM manipulation code instead.

   Read the full bite: How does Svelte update the DOM without a Virtual DOM?

3. Question 3 of 30

   How does Vue's reactivity system primarily ensure UI components update automatically with data changes?

   • aIt periodically compares the current data state with a previous snapshot and re-renders if differences are found.
   • bIt wraps data objects in JavaScript Proxies to intercept property access and modification, triggering updates when changes occur.
   • cIt directly modifies the DOM elements associated with changed data properties using specialized browser APIs.
   • dIt compiles templates into highly optimized JavaScript functions that re-execute only when their bound variables are explicitly reassigned.
   Show the answer

   Answer: b · It wraps data objects in JavaScript Proxies to intercept property access and modification, triggering updates when changes occur.

   Vue's reactivity system uses JavaScript Proxies to wrap data, intercepting 'get' operations to track dependencies and 'set' operations to notify subscribers for updates. Option A describes a polling mechanism, which is not how Vue's event-driven reactivity works.

   Read the full bite: Vue's Reactivity: JavaScript That Acts Like a Spreadsheet

4. Question 4 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?

5. Question 5 of 30

   When you write v-model or [(ngModel)] in a template, what is the framework actually doing under the hood?

   • aIt creates a direct reactive bridge that bypasses props and events to keep DOM and state in sync
   • bIt compiles to a one-time value assignment and a manual addEventListener call on the native DOM element
   • cIt is shorthand for binding a value property downward and listening for an update event upward
   • dIt allows the input element to mutate the component state directly, breaking unidirectional flow
   Show the answer

   Answer: c · It is shorthand for binding a value property downward and listening for an update event upward

   Two-way binding is syntactic sugar for a property pushing data down and an event pushing changes back up. Option D is a common misconception: the view does not mutate state directly; frameworks use explicit events to update the model.

   Read the full bite: Explain two-way data binding and provide input binding syntax

6. Question 6 of 30

   In classic Svelte, why does reassigning an array with spread trigger an update while calling push on the same array does not?

   • aJavaScript arrays are immutable by default, so push creates a new reference that Svelte ignores.
   • bSvelte relies on a virtual DOM diff that cannot detect in-place mutations like push, unlike React.
   • cThe Svelte compiler instruments assignment operators but not method calls, so push is invisible to the reactive system.
   • dSvelte requires immutable updates, so mutating the existing array with push bypasses change detection.
   Show the answer

   Answer: c · The Svelte compiler instruments assignment operators but not method calls, so push is invisible to the reactive system.

   Classic Svelte's compiler transforms assignment expressions into reactive setters, but it does not wrap method calls like push, so the reactive graph never hears about the change. The virtual DOM distractor is wrong because Svelte updates DOM nodes surgically via compiled code rather than relying on a virtual DOM diff.

   Read the full bite: Why does todos.push miss Svelte updates but spread works?

7. Question 7 of 30

   Which accurately describes a key difference between Vue 3's ref() and reactive()?

   • aref() and reactive() can be swapped without changing how state is accessed in code.
   • bref() requires accessing state through .value in script, while reactive() allows direct property access.
   • cref() is intended only for primitive values, while reactive() handles objects.
   • dref() automatically unwraps in script but requires .value in templates.
   Show the answer

   Answer: b · ref() requires accessing state through .value in script, while reactive() allows direct property access.

   ref() wraps any value in an object accessed via .value in script, while reactive() returns a proxy you access directly. Option C is a tempting misconception: ref() is not limited to primitives and is the recommended default for most state.

   Read the full bite: Vue 3 ref() vs reactive(): differences and when to use each

8. Question 8 of 30

   In Svelte 5, you declare an array with let items = $state([1, 2]) and later call items.push(3). What is the result?

   • aYou must wrap the push call in an $effect rune to trigger the update
   • bThe compiler converts the push call into an immutable spread operation
   • cThe UI updates automatically because the array is wrapped in a reactive proxy
   • dNothing updates until you reassign the items variable to itself
   Show the answer

   Answer: c · The UI updates automatically because the array is wrapped in a reactive proxy

   In Svelte 5, the $state rune wraps arrays in proxies that intercept mutations like push, so the UI updates immediately without reassignment. Reassigning the variable to itself is a legacy pattern that is unnecessary when using runes.

   Read the full bite: How do you update Svelte arrays and objects to trigger reactivity?

9. Question 9 of 30

   You need to display a list filtered by user input and fetch remote data when a route parameter changes. Which approach follows Vue's reactivity design?

   • aUse watch to filter the list into a reactive ref and computed to trigger the fetch when the parameter changes.
   • bUse computed to derive the filtered list for the template and watch to execute the fetch when the parameter changes.
   • cUse computed for both filtering the list and fetching remote data, since computed automatically caches async results.
   • dUse watch for both filtering the list and fetching data, because watchers are more flexible than computed.
   Show the answer

   Answer: b · Use computed to derive the filtered list for the template and watch to execute the fetch when the parameter changes.

   Computed is for synchronous derived state and caches its result, while watch is for imperative side effects like API calls. Option C is tempting but wrong because computed must be synchronous and pure, so async work inside it breaks reactivity expectations.

   Read the full bite: Fundamental difference between Vue computed and watcher with examples

10. Question 10 of 30

    Which of the following must be true for a plain JavaScript object to act as a valid Svelte store?

    • aIt must implement a subscribe method that accepts a callback and returns an unsubscribe function.
    • bIt must be referenced with the $ prefix wherever it is used in code.
    • cIt must expose set and update methods so components can modify it.
    • dIt must be created using writable() or derived() from svelte/store.
    Show the answer

    Answer: a · It must implement a subscribe method that accepts a callback and returns an unsubscribe function.

    Svelte recognizes any object as a store as long as it provides a subscribe method that takes a callback and returns an unsubscribe function. Option D is tempting but wrong because the $ prefix is consumer-side auto-subscription syntax in .svelte files, not part of the store's definition contract.

    Read the full bite: How do Svelte Stores work and how do you create custom ones?

11. Question 11 of 30

    What is the consequence of returning a cleanup function from an asynchronous onMount callback in Svelte 5?

    • aThe cleanup function will not be registered, leading to potential memory leaks upon component destruction.
    • bThe cleanup function will be correctly registered and executed when the component is destroyed.
    • cThe onMount callback will immediately throw an error, preventing component initialization.
    • dThe component will fail to render its initial DOM structure.
    Show the answer

    Answer: a · The cleanup function will not be registered, leading to potential memory leaks upon component destruction.

    An asynchronous onMount callback implicitly returns a Promise, not the cleanup function itself. Therefore, Svelte cannot register the intended cleanup function, which can lead to memory leaks. Option B is incorrect because the Promise is not interpreted as a cleanup function.

    Read the full bite: Svelte Lifecycle: Mount, Destroy, and Tick

12. Question 12 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

13. Question 13 of 30

    What is a critical limitation of Svelte's `$: ` reactive assignments?

    • aThey only track direct variable dependencies, not changes within functions called.
    • bThey cannot be used to trigger side effects like logging.
    • cThey require explicit manual calls to update derived values.
    • dThey are only suitable for server-side rendering, not client-side.
    Show the answer

    Answer: a · They only track direct variable dependencies, not changes within functions called.

    The card explicitly states that the compiler only tracks direct dependencies and not those hidden inside function calls, which is a key limitation. The card also provides `$: console.log(count)` as an example of using it for side effects, making option B incorrect.

    Read the full bite: Svelte's Reactive Assignments with `$: `

14. Question 14 of 30

    Which scenario would lead to a loss of reactivity or an error when using Vue's Composition API?

    • aDestructuring a property from a reactive() object into a local variable.
    • bAssigning a new object to a ref() variable (e.g., myRef.value = { new: 'data' }).
    • cAccessing the value of a ref() variable using myRef.value.
    • dModifying a property of an object wrapped by reactive() (e.g., myObject.prop = 'new value').
    Show the answer

    Answer: a · Destructuring a property from a reactive() object into a local variable.

    The card states that "losing reactivity when destructuring" is a major footgun with reactive(). The destructured variable becomes a plain value, losing its connection to the reactive state. Options A, C, and D describe correct and intended uses of ref() and reactive() respectively, which maintain reactivity.

    Read the full bite: ref() vs. reactive(): Vue's Two Flavors of Reactivity

15. Question 15 of 30

    According to the card, what is the primary reason to use a computed property for complex logic instead of an in-template expression?

    • aTo allow the derived value to be easily modified by user input.
    • bTo ensure the derived value is always reactive and updates automatically.
    • cTo keep templates clean and readable by moving complex calculations out of the markup.
    • dTo boost application performance by pre-calculating and caching the value before rendering.
    Show the answer

    Answer: c · To keep templates clean and readable by moving complex calculations out of the markup.

    The card explicitly states that computed properties exist "to move this complex, reactive logic out of the template" to keep them "clean and readable" and "separate calculation from presentation." While caching (option D) is a benefit of computed properties, the primary reason highlighted for using them with complex logic over in-template expressions is the improvement in template clarity and maintainability.

    Read the full bite: Vue Computed Properties: Derived Values for Cleaner Templates

16. Question 16 of 30

    A developer needs to implement a feature in a Vue application. Which of the following tasks is best suited for a Vue watcher?

    • aInitiating an asynchronous API request to fetch data whenever a specific route parameter changes.
    • bFiltering a large dataset based on multiple user-selected criteria to display a subset of data.
    • cCalculating the total price of items in a shopping cart based on individual item prices and quantities.
    • dDynamically generating a "fullName" string by concatenating "firstName" and "lastName" properties.
    Show the answer

    Answer: a · Initiating an asynchronous API request to fetch data whenever a specific route parameter changes.

    Watchers are designed for performing "side effects" like API calls in response to state changes, as described in option A. Options A, B, and D involve deriving new values or filtered data from existing state, which is the primary purpose of a computed property, not a watcher.

    Read the full bite: Vue Watchers: Running Code on State Changes

17. Question 17 of 30

    For which of the following use cases would a Svelte derived store be the most appropriate choice?

    • aStoring the user's selected theme preference (e.g., 'dark' or 'light').
    • bHolding the value of a form input field that the user is actively typing into.
    • cDisplaying a "Welcome, [Full Name]!" message based on separate first and last name stores.
    • dManaging the current page number in a pagination component.
    Show the answer

    Answer: c · Displaying a "Welcome, [Full Name]!" message based on separate first and last name stores.

    A derived store is ideal for values that are purely computed from other stores, like combining first and last names into a full name. Options A, B, and D describe primary sources of truth or direct user input, which require writable stores.

    Read the full bite: Svelte Derived Stores: Reactive Values from Other Stores

18. Question 18 of 30

    In Svelte 5, how do you bind an input to reactive state and log its validity after every keystroke?

    • aUse $derived for the input value and validate it in a template expression.
    • bUse a plain let variable and read it inside an $effect.
    • cUse $state for the input and run validation logic inside an $effect that reads it.
    • dUse $state for the input and mutate it inside an $effect to auto-correct invalid input.
    Show the answer

    Answer: c · Use $state for the input and run validation logic inside an $effect that reads it.

    B is correct because $state creates tracked reactive state, and an $effect automatically re-runs whenever state it reads changes. C is tempting but wrong because writing to the same $state variable inside an effect that reads it creates an infinite loop.

    Read the full bite: Bind an input to a variable and validate with reactivity

19. Question 19 of 30

    When displaying a password mismatch error in Vue based on two reactive inputs, which approach best follows the framework's intended reactivity patterns?

    • aUse a watcher on both fields that updates a separate isMatch reactive flag whenever either password value changes.
    • bDefine a computed boolean that evaluates whether the two password fields match and bind the error display directly to it.
    • cUse a watcher to trigger an async API call that verifies the passwords match and returns the validation result.
    • dUse a watcher on the confirmPassword field to directly toggle the error element's CSS display property in the DOM.
    Show the answer

    Answer: b · Define a computed boolean that evaluates whether the two password fields match and bind the error display directly to it.

    A computed property declaratively derives state from existing reactive data and caches the result, re-evaluating only when dependencies change. Option A is tempting but wrong because manually syncing an isMatch flag in a watcher abandons Vue's automatic caching and creates a synchronization hazard where the flag can drift from the inputs.

    Read the full bite: Validate matching Vue passwords: computed property or watcher?

20. Question 20 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?

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

    When building a useFetch composable in Vue 3, where should the data, loading, and error refs be created to guarantee each component gets its own independent state?

    • aIn a Pinia store that the composable imports and returns to the component
    • bAt the top level of the composable's module so all components share a single reactive source
    • cInside the useFetch function so every call returns a fresh set of refs
    • dInside the component's setup before calling useFetch, then passed in as arguments
    Show the answer

    Answer: c · Inside the useFetch function so every call returns a fresh set of refs

    Declaring refs inside the useFetch function treats it as a factory, giving each component instance isolated reactive state. Placing them at the module level creates a singleton, causing every consumer to overwrite the same shared data.

    Read the full bite: How do you implement a data-fetching Composable in Vue 3?

23. Question 23 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?

24. Question 24 of 30

    Which scenario best fits a computed property instead of a method in Vue?

    • aHandling a click event that toggles a visibility flag
    • bFiltering a list by a search term passed as a template argument
    • cSending analytics data whenever a user toggles a checkbox
    • dBuilding a full name from reactive firstName and lastName fields
    Show the answer

    Answer: d · Building a full name from reactive firstName and lastName fields

    Computed properties are designed for cached, derived state that depends on reactive data and does not accept arguments, making a full name the ideal fit. Filtering by a template argument is a tempting distractor because it resembles derived data, but computed getters cannot take parameters, so a method is required there.

    Read the full bite: Vue computed vs method: performance difference and when to choose each?

25. Question 25 of 30

    When a reactive variable changes in a Svelte component, what does the runtime do differently than a VDOM framework?

    • aIt relies on a smaller, optimized virtual DOM that skips diffing for static branches
    • bIt executes pre-generated imperative code that mutates only the affected real DOM nodes
    • cIt avoids all runtime overhead because Svelte compiles to pure DOM instructions with no runtime
    • dIt diffs a compiled static tree against a lightweight virtual snapshot to isolate changes
    Show the answer

    Answer: b · It executes pre-generated imperative code that mutates only the affected real DOM nodes

    Svelte's compiler generates imperative code that calls native DOM APIs to surgically update only affected nodes, eliminating virtual tree creation and diffing. The zero-runtime claim is a common misconception; Svelte still includes a small runtime, but it avoids reconciliation overhead rather than eliminating all runtime work.

    Read the full bite: How does Svelte surgically update the DOM without VDOM?

26. Question 26 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?

27. Question 27 of 30

    When Vue re-renders a component after a state change, what specific job does the virtual DOM perform before the browser screen updates?

    • aIt translates the render output into Shadow DOM for encapsulated browser updates
    • bIt rebuilds the entire real DOM subtree from scratch to ensure correctness
    • cIt generates a lightweight tree that is diffed against the prior tree to identify minimal real DOM operations
    • dIt directly modifies the real DOM nodes to match the new component state
    Show the answer

    Answer: c · It generates a lightweight tree that is diffed against the prior tree to identify minimal real DOM operations

    The virtual DOM is an in-memory intermediate representation, so Vue diffs the new tree against the old one to compute and apply only the smallest necessary real DOM updates. Option D is tempting but wrong because it reflects the common misconception that the virtual DOM directly manipulates the browser DOM without an intermediate diffing step.

    Read the full bite: What is the Virtual DOM's role during a Vue state update?

28. Question 28 of 30

    Which statement best contrasts how Vue 3 and Angular with Zone.js propagate a state mutation to the component tree?

    • aVue tracks property access during render to notify only dependent effects, while Zone.js schedules a top-down dirty-checking pass over the entire tree.
    • bBoth frameworks use push-based reactivity, but Vue tracks dependencies per property while Angular tracks them per async task.
    • cAngular natively intercepts state mutations with Proxies to update specific components, whereas Vue patches global async APIs to trigger tree-wide checks.
    • dVue diffs the virtual DOM to detect state changes and targets specific components, while Zone.js proxies async APIs to skip unchanged branches.
    Show the answer

    Answer: a · Vue tracks property access during render to notify only dependent effects, while Zone.js schedules a top-down dirty-checking pass over the entire tree.

    Vue 3 uses Proxies to intercept mutations and push updates only to subscriber effects that read the property during render, while Zone.js monkey-patches async APIs to schedule a pull-based, top-down dirty check of the whole tree. Distractor A is tempting but wrong because Vue does not use virtual DOM diffing to detect state changes; it uses Proxies, and VDOM diffing happens only during render.

    Read the full bite: Compare Angular Zone.js and Vue 3 Proxy reactivity

29. Question 29 of 30

    When count += 1 executes in Svelte 5, what mechanism ensures the DOM reflects the new value without virtual DOM diffing?

    • aThe compiler transforms count into a Proxy-backed object whose setter automatically updates the virtual DOM tree during execution.
    • bThe compiler treats $state as a build-time construct and emits imperative code that directly updates the specific DOM nodes.
    • cThe $state rune acts as a runtime function that registers count in a reactive store, triggering virtual DOM reconciliation on change.
    • dA JavaScript Proxy wraps count and intercepts the assignment at runtime to schedule affected DOM nodes for update.
    Show the answer

    Answer: b · The compiler treats $state as a build-time construct and emits imperative code that directly updates the specific DOM nodes.

    The compiler intercepts the $state rune during compilation and generates imperative DOM update logic, so reactivity happens at build time rather than through runtime Proxies or virtual DOM diffing. Option C is tempting because runes look like React hooks, but $state is a compiler construct, not a runtime store registration.

    Read the full bite: How does Svelte compile count += 1 into DOM updates?

30. Question 30 of 30

    What was the primary benefit of using immutable={true} in Svelte 3/4 components?

    • aIt enabled Svelte to perform faster change detection by only checking object references.
    • bIt was essential for compatibility with Svelte 5's new reactivity runes.
    • cIt automatically prevented developers from accidentally mutating state directly.
    • dIt allowed components to update the UI even when state objects were mutated in place.
    Show the answer

    Answer: a · It enabled Svelte to perform faster change detection by only checking object references.

    The immutable={true} option instructed Svelte to use fast referential checks (oldValue === newValue) for updates, leading to a performance boost. It did not prevent mutation; rather, it relied on the developer's promise not to mutate, and mutations would not be detected.

    Read the full bite: Svelte's Legacy immutable={true} Optimization