Context with stores in Svelte - Performance & Optimization

Performance: Context with stores

MEDIUM IMPACT

This affects how efficiently state is shared and updated across components without unnecessary DOM updates or re-renders.

Sharing reactive state across multiple nested components

Svelte

import { writable } from 'svelte/store';
import { setContext, getContext } from 'svelte';

const count = writable(0);
setContext('countStore', count);

// In nested components
const count = getContext('countStore');

Using context avoids prop drilling and limits re-renders to components that actually use the store.

📈 Performance Gainreduces re-renders to only subscribed components, improving input responsiveness

Sharing reactive state across multiple nested components

Svelte

import { writable } from 'svelte/store';
const count = writable(0);

// Passing store as a prop through many components
<ComponentA count={count} />

// Each intermediate component passes count down as prop

Passing stores through many props causes unnecessary re-renders and prop drilling, increasing DOM updates and slowing interaction.

📉 Performance Costtriggers multiple re-renders and prop updates for each intermediate component

Performance Comparison

Pattern	DOM Operations	Reflows	Paint Cost	Verdict
Passing stores via props through many components	Many prop updates and component re-renders	Multiple reflows triggered by each update	Higher paint cost due to repeated updates	[X] Bad
Providing stores via Svelte context	Only subscribed components update	Single reflow per store update	Lower paint cost due to targeted updates	[OK] Good

Rendering Pipeline

When a store value changes, only components subscribed to that store update. Using context to provide the store avoids unnecessary prop updates and reflows in intermediate components.

→JavaScript Execution

→Style Calculation

→Layout

→Paint

⚠️ BottleneckJavaScript Execution due to unnecessary component updates

Core Web Vital Affected

INP

This affects how efficiently state is shared and updated across components without unnecessary DOM updates or re-renders.

Optimization Tips

1Use Svelte context to provide stores to avoid prop drilling.

2Subscribe only in components that need the store to limit updates.

3Avoid passing stores through many intermediate components to reduce re-renders.

Performance Quiz - 3 Questions

What is a main performance benefit of using Svelte context to provide stores instead of passing them as props?

A It increases the bundle size significantly.

B It reduces unnecessary component re-renders by avoiding prop drilling.

C It triggers more layout recalculations.

D It disables reactive updates in components.

DevTools: Performance

How to check: Record a performance profile while interacting with the app. Look for excessive component updates or re-renders in the flame chart.

What to look for: Fewer component re-renders and shorter scripting times indicate better performance with context stores.

Practice

1. In Svelte, what is the main purpose of using setContext and getContext with stores?

easy

A. To create a new store that is only used inside one component

B. To handle HTTP requests inside components

C. To style components globally using CSS variables

D. To share reactive data easily between components without passing props through many layers

Solution

1. Step 1: Understand the role of setContext and getContext

   These functions allow sharing data between components without manually passing props down the tree.

2. Step 2: Recognize the benefit of using stores with context

   Stores provide reactive data, and context lets multiple components access the same store easily.

3. Final Answer:

   To share reactive data easily between components without passing props through many layers -> Option D

4. Quick Check:

   Context with stores = share reactive data [OK]

Hint: Context shares stores to avoid prop drilling [OK]

Common Mistakes:

• Thinking context creates new stores instead of sharing
• Confusing context with styling or HTTP handling
• Assuming context replaces all props

2. Which of the following is the correct way to provide a store via context in a Svelte parent component?

easy

A. import { getContext } from 'svelte'; getContext('key', store);

B. import { setContext } from 'svelte'; setContext('key', store);

C. import { setContext } from 'svelte'; setContext(store);

D. import { createContext } from 'svelte'; createContext('key', store);

Solution

1. Step 1: Recall the correct import and usage for setting context

   Use setContext from 'svelte' with a key and a value (store).

2. Step 2: Identify the correct syntax

   The correct call is setContext('key', store); to provide the store under a key.

3. Final Answer:

   import { setContext } from 'svelte'; setContext('key', store); -> Option B

4. Quick Check:

   setContext with key and store = import { setContext } from 'svelte'; setContext('key', store); [OK]

Hint: Use setContext with key and store in parent [OK]

Common Mistakes:

• Using getContext instead of setContext to provide
• Omitting the key argument in setContext
• Using non-existent createContext function

3. Given the following Svelte code, what will be logged to the console?

/* Parent.svelte */

medium

A. 5

B. undefined

C. Error: countStore not found

D. 0

Solution

1. Step 1: Understand the store creation and context setting

   The parent creates a writable store with initial value 5 and sets it in context under 'countStore'.

2. Step 2: Child retrieves the store and subscribes

   The child gets the store from context and subscribes to log its current value, which is 5.

3. Final Answer:

   5 -> Option A

4. Quick Check:

   Store initial value logged = 5 [OK]

Hint: Store initial value logs on subscribe [OK]

Common Mistakes:

• Expecting undefined if context key is wrong
• Confusing setContext and getContext usage
• Assuming subscription logs nothing initially

4. What is the error in this Svelte child component code that tries to get a store from context?

medium

A. Cannot subscribe to context value

B. Using getContext instead of setContext

C. Missing key argument in getContext call

D. Import statement is incorrect

Solution

1. Step 1: Check getContext usage

   getContext requires a key argument to retrieve the correct context value.

2. Step 2: Identify the missing key

   The code calls getContext() without any argument, causing an error.

3. Final Answer:

   Missing key argument in getContext call -> Option C

4. Quick Check:

   getContext needs key argument [OK]

Hint: Always pass key to getContext [OK]

Common Mistakes:

• Calling getContext without key
• Confusing getContext with setContext
• Assuming context value is not subscribable

5. You want to share a writable store with a default value of 0 across multiple nested components using context. Which approach correctly sets and uses this store so that updates in any child reflect everywhere?

hard

A. In parent: setContext('count', writable(0)); In children: const count = getContext('count'); Then use count.update() or count.set()

B. In parent: const count = writable(0); In children: import the store directly and use it

C. In parent: setContext('count', 0); In children: const count = getContext('count'); Then update count directly

D. In parent: setContext('count', writable(0)); In children: const count = getContext('count'); But children cannot update the store

Solution

1. Step 1: Provide a writable store via context in the parent

   Use setContext('count', writable(0)); to share a reactive store.

2. Step 2: Retrieve the store in children and update it

   Children get the store with getContext('count'); and can call update() or set() to change the value, reflecting everywhere.

3. Final Answer:

   In parent: setContext('count', writable(0)); In children: const count = getContext('count'); Then use count.update() or count.set() -> Option A

4. Quick Check:

   Writable store in context updates everywhere [OK]

Hint: Set writable store in context, children get and update it [OK]

Common Mistakes:

• Passing raw value instead of store in context
• Importing store directly instead of using context
• Assuming children cannot update shared store