Context vs stores decision in Svelte - Performance Comparison

Performance: Context vs stores decision

MEDIUM IMPACT

This affects how state sharing impacts page load speed and interaction responsiveness in Svelte apps.

Sharing reactive state across multiple unrelated components

Svelte

Using a Svelte store for global reactive state:

// userStore.js
import { writable } from 'svelte/store';
export const user = writable(null);

// AnyComponent.svelte
<script>
  import { user } from './userStore.js';

  user.subscribe(value => { /* react to changes */ });
</script>

Stores provide a centralized reactive state with efficient subscription management, minimizing unnecessary updates and improving responsiveness.

📈 Performance GainReduces re-renders to only subscribed components, improving INP and CPU usage.

Sharing reactive state across multiple unrelated components

Svelte

Using context to pass state deeply and across many components manually:

// Parent.svelte
<script>
  import { setContext } from 'svelte';
  import { user } from './userStore.js';
  setContext('user', user);
</script>

// DeepChild.svelte
<script>
  import { getContext } from 'svelte';
  const user = getContext('user');
  user.subscribe(value => { /* react to changes */ });
</script>

Context is designed for passing data down a component tree, not for global reactive state. Using it globally causes many components to re-render unnecessarily and complicates updates.

📉 Performance CostTriggers multiple re-renders and reactive updates across unrelated components, increasing INP and CPU usage.

Performance Comparison

Pattern	DOM Operations	Reflows	Paint Cost	Verdict
Using context for global reactive state	High due to many subscriptions	Multiple reflows from unnecessary updates	High paint cost from frequent re-renders	[X] Bad
Using stores for global reactive state	Optimized subscriptions only where needed	Minimal reflows limited to subscribed components	Lower paint cost due to selective updates	[OK] Good
Using stores for static data	Unnecessary subscription overhead	Unneeded reflows on rare changes	Moderate paint cost	[!] OK
Using context for static data	No subscriptions, minimal DOM ops	No reflows triggered by data changes	Minimal paint cost	[OK] Good

Rendering Pipeline

Context and stores affect the reactive update phase of rendering. Stores trigger reactive subscriptions causing component updates, while context provides static or scoped data without reactive triggers unless combined with stores.

→Reactive Update

→Layout

→Paint

⚠️ BottleneckReactive Update stage due to subscription notifications and component re-renders.

Core Web Vital Affected

INP

This affects how state sharing impacts page load speed and interaction responsiveness in Svelte apps.

Optimization Tips

1Use stores for global reactive state to minimize unnecessary component updates.

2Use context for static or scoped data to avoid subscription overhead.

3Avoid passing reactive state via context globally to reduce re-renders.

Performance Quiz - 3 Questions

Which pattern is best for sharing global reactive state in Svelte for optimal performance?

A Using Svelte stores

B Using context for all state

C Passing props deeply

D Using global variables

DevTools: Performance

How to check: Record a performance profile while interacting with components using context or stores. Look for scripting and rendering times related to reactive updates.

What to look for: High scripting time and frequent component re-renders indicate inefficient state sharing. Efficient patterns show fewer reactive updates and lower CPU usage.

Practice

1. In Svelte, when should you use context instead of stores?

easy

A. To manage asynchronous data fetching

B. To share data only between a parent and its child components locally

C. To share reactive data globally across unrelated components

D. To create CSS styles scoped to a component

Solution

1. Step 1: Understand context usage

   Context is designed to share data locally down the component tree without passing props explicitly.

2. Step 2: Compare with stores

   Stores are for global reactive data accessible anywhere by importing, not limited to parent-child.

3. Final Answer:

   To share data only between a parent and its child components locally -> Option B

4. Quick Check:

   Context = local sharing [OK]

Hint: Context is for local, stores for global reactive data [OK]

Common Mistakes:

• Using stores for local-only data sharing
• Confusing context with global state management
• Thinking context is reactive globally
• Using context for styling or async tasks

2. Which of the following is the correct way to set a context value in a Svelte component?

easy

A. import { createContext } from 'svelte'; createContext('key', value);

B. import { useContext } from 'svelte'; useContext('key', value);

C. import { setContext } from 'svelte'; setContext('key', value);

D. import { setStore } from 'svelte'; setStore('key', value);

Solution

1. Step 1: Recall Svelte context API

   Svelte uses setContext to provide a value to child components.

2. Step 2: Check import and usage

   The correct import is from 'svelte' and the function is setContext with key and value.

3. Final Answer:

   import { setContext } from 'svelte'; setContext('key', value); -> Option C

4. Quick Check:

   setContext = provide context [OK]

Hint: Use setContext to provide data down the tree [OK]

Common Mistakes:

• Using createContext or useContext which are React terms
• Trying to set stores with setContext
• Wrong import paths or function names
• Confusing setContext with reactive stores

3. Given this Svelte 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, 5]

D. [1, 5, 6]

Solution

1. Step 1: Understand initial subscription call

   Subscribing to a writable store immediately calls the callback with the current value, which is 0.

2. Step 2: Trace set and update calls

   Then count.set(5) triggers callback with 5, and count.update(n => n + 1) triggers callback with 6.

3. Final Answer:

   [0, 5, 6] -> Option A

4. Quick Check:

   Subscription calls on current and changes [OK]

Hint: Subscription logs current value immediately [OK]

Common Mistakes:

• Ignoring initial subscription call
• Mixing order of set and update
• Assuming update starts from 0 after set
• Confusing subscribe behavior with events

4. What is wrong with this Svelte code snippet that tries to share data using context?

import { getContext } from 'svelte';

const value = getContext('user');

console.log(value);

medium

A. It tries to get context outside a component setup, causing undefined

B. It uses getContext instead of setContext to provide data

C. The key 'user' must be an object, not a string

D. getContext requires two arguments, key and default value

Solution

1. Step 1: Check context usage location

   getContext must be called inside a component's script during initialization, not in a module scope.

2. Step 2: Understand consequence

   Calling it outside component setup returns undefined because no context is set yet.

3. Final Answer:

   It tries to get context outside a component setup, causing undefined -> Option A

4. Quick Check:

   getContext only works inside component setup [OK]

Hint: Use getContext only inside component scripts [OK]

Common Mistakes:

• Calling getContext in module scope
• Confusing getContext with setContext usage
• Assuming string keys must be objects
• Expecting getContext to have default value argument

5. You want to share a reactive theme color across many unrelated components in a Svelte app. Which approach is best and why?

hard

A. Use a global variable for shared data

B. Use context API for local tree sharing

C. Pass props through all components manually

D. Use a writable store for global reactive data

Solution

1. Step 1: Identify sharing scope

   The theme color must be shared globally across unrelated components, not just parent-child.

2. Step 2: Choose reactive global sharing

   Writable stores provide reactive global state accessible by importing anywhere.

3. Step 3: Evaluate other options

   Context is local only, props are tedious for many components, global variables lack reactivity.

4. Final Answer:

   Use a writable store for global reactive data -> Option D

5. Quick Check:

   Stores = global reactive sharing [OK]

Hint: Use stores for global reactive data, context for local only [OK]

Common Mistakes:

• Using context for global sharing
• Passing props through many unrelated components
• Using global variables without reactivity
• Ignoring reactivity needs for theme changes