Bird
Raised Fist0
Svelteframework~8 mins

Why stores manage shared state in Svelte - Performance Evidence

Choose your learning style10 modes available
Performance: Why stores manage shared state
MEDIUM IMPACT
This affects how efficiently the app updates UI when multiple components share data, impacting interaction responsiveness and rendering speed.
Sharing state between multiple Svelte components
Svelte
import { writable } from 'svelte/store';

export const count = writable(0);

// Components subscribe to 'count' store and update reactively
function increment() {
  count.update(n => n + 1);
}
Stores provide a single source of truth with reactive subscriptions, minimizing redundant DOM updates and syncing UI efficiently.
📈 Performance GainSingle reflow per update with automatic batching, improving interaction responsiveness.
Sharing state between multiple Svelte components
Svelte
let count = 0;

// Each component imports and modifies 'count' directly without a store
function increment() {
  count += 1;
  // No reactive updates across components
}
Directly modifying shared variables causes inconsistent UI and forces manual update logic, leading to extra re-renders or stale views.
📉 Performance CostTriggers multiple unnecessary reflows and repaints due to manual DOM updates and duplicated state logic.
Performance Comparison
PatternDOM OperationsReflowsPaint CostVerdict
Direct shared variable modificationMultiple manual DOM updatesMultiple reflows per updateHigh paint cost due to redundant updates[X] Bad
Using Svelte writable storesReactive updates only on subscribed componentsSingle reflow per state changeLow paint cost with efficient batching[OK] Good
Rendering Pipeline
Stores centralize state changes, triggering reactive updates only where needed. When a store value changes, Svelte schedules updates to subscribed components, minimizing layout recalculations and paints.
→Style Calculation
→Layout
→Paint
⚠️ BottleneckLayout and Paint stages due to unnecessary updates when state is managed poorly.
Core Web Vital Affected
INP
This affects how efficiently the app updates UI when multiple components share data, impacting interaction responsiveness and rendering speed.
Optimization Tips
1Use Svelte stores to centralize shared state and enable reactive updates.
2Avoid direct shared variable modifications to prevent redundant DOM updates.
3Batch state changes to minimize layout recalculations and paint operations.
Performance Quiz - 3 Questions
Test your performance knowledge
What is the main performance benefit of using Svelte stores for shared state?
AThey force full page reloads on state change
BThey increase bundle size significantly
CThey batch updates and trigger fewer reflows
DThey disable reactive updates
DevTools: Performance
How to check: Record a performance profile while interacting with components sharing state. Look for number of layout and paint events triggered by state changes.
What to look for: Fewer layout recalculations and paint events indicate efficient shared state management with stores.

Practice

(1/5)
1. Why do Svelte stores help manage shared state in an app?
easy
A. They store data only for one component at a time.
B. They make the app run faster by skipping updates.
C. They keep data in one place and update all parts automatically.
D. They prevent any data changes after initialization.

Solution

  1. Step 1: Understand the role of stores

    Svelte stores hold shared data centrally so multiple components can access it easily.
  2. Step 2: Recognize automatic updates

    When the store data changes, all components using it update automatically, keeping UI in sync.
  3. Final Answer:

    They keep data in one place and update all parts automatically. -> Option C
  4. Quick Check:

    Shared data + auto update = A [OK]
Hint: Stores centralize data and auto-update components [OK]
Common Mistakes:
  • Thinking stores only speed up the app
  • Believing stores hold data per component only
  • Assuming stores freeze data after setup
2. Which of the following is the correct way to import and create a writable store in Svelte?
easy
A. import writable from 'svelte'; const count = writable(0);
B. import { writable } from 'svelte/store'; const count = store(0);
C. import { store } from 'svelte/store'; const count = store(0);
D. import { writable } from 'svelte/store'; const count = writable(0);

Solution

  1. Step 1: Check import syntax

    The writable store is imported from 'svelte/store' using curly braces around writable.
  2. Step 2: Verify store creation

    Creating a writable store uses writable(initialValue), so writable(0) is correct.
  3. Final Answer:

    import { writable } from 'svelte/store'; const count = writable(0); -> Option D
  4. Quick Check:

    Correct import + writable() = B [OK]
Hint: Use curly braces to import writable from 'svelte/store' [OK]
Common Mistakes:
  • Importing writable without braces
  • Using 'store' instead of 'writable'
  • Calling store() instead of writable()
3. Given this Svelte store code, what will be logged to the console?
import { writable } from 'svelte/store';
const count = writable(0);
count.subscribe(value => console.log(value));
count.set(5);
count.update(n => n + 1);
medium
A. 0, 5, 6
B. 5, 6
C. 0, 1, 6
D. 0, 5, 5

Solution

  1. Step 1: Understand subscription initial call

    Subscribing to a writable store immediately calls the callback with the current value, so 0 is logged first.
  2. Step 2: Follow set and update calls

    count.set(5) changes value to 5, logging 5. Then count.update(n => n + 1) adds 1, logging 6.
  3. Final Answer:

    0, 5, 6 -> Option A
  4. Quick Check:

    Subscribe logs initial + set + update values = A [OK]
Hint: Subscribe logs current value immediately, then on changes [OK]
Common Mistakes:
  • Ignoring initial subscription call
  • Thinking update replaces value instead of adding
  • Missing the last logged value
4. What is wrong with this Svelte store usage?
import { writable } from 'svelte/store';
const user = writable({ name: 'Alice' });

// In component
user.name = 'Bob';
medium
A. The store must be declared with let, not const.
B. Directly changing user.name does not update the store value.
C. Writable stores cannot hold objects as values.
D. The store should be imported from 'svelte' not 'svelte/store'.

Solution

  1. Step 1: Identify how to update store values

    Writable stores require using set() or update() to change their value, not direct property assignment.
  2. Step 2: Explain why direct property change fails

    Changing user.name directly modifies the object but does not notify the store, so subscribers won't update.
  3. Final Answer:

    Directly changing user.name does not update the store value. -> Option B
  4. Quick Check:

    Use set() or update() to change store values [OK]
Hint: Always use set() or update() to change store data [OK]
Common Mistakes:
  • Trying to mutate store value properties directly
  • Importing writable incorrectly
  • Thinking const prevents store updates
5. You want to share a counter value across multiple components and update it from any of them. Which approach best uses Svelte stores to achieve this?
hard
A. Create a writable store in a separate file and import it in all components.
B. Pass the counter value as a prop from parent to child components only.
C. Use local variables in each component and sync them manually.
D. Create a store inside each component separately.

Solution

  1. Step 1: Understand shared state needs

    To share and update data across components, a single source of truth is needed.
  2. Step 2: Evaluate store usage

    Creating a writable store in one file and importing it everywhere ensures all components share and react to the same data.
  3. Step 3: Compare other options

    Passing props only works top-down and is cumbersome for many components; local variables are isolated; separate stores cause desync.
  4. Final Answer:

    Create a writable store in a separate file and import it in all components. -> Option A
  5. Quick Check:

    Single shared store file = C [OK]
Hint: Use one store file imported by all components [OK]
Common Mistakes:
  • Trying to sync local variables manually
  • Passing props for deeply nested sharing
  • Creating multiple stores causing inconsistent state
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard