Context vs stores decision in Svelte - Trade-offs & Expert Analysis

Overview - Context vs stores decision

What is it?

In Svelte, context and stores are two ways to share data between components. Context lets a parent component pass data directly to its descendants without using props. Stores are reactive objects that hold data and can be used anywhere in the app to share state. Both help components communicate, but they work differently and suit different needs.

Why it matters

Without context or stores, sharing data between components can become messy and repetitive, especially in large apps. Props would need to be passed down many levels, making code hard to maintain. Context and stores simplify this by providing clean, efficient ways to share data, improving app structure and developer experience.

Where it fits

Before learning this, you should understand basic Svelte components and props. After this, you can explore advanced state management, custom stores, and SvelteKit app architecture.

Mental Model

Core Idea

Context is like a secret message passed down a family tree, while stores are like a shared bulletin board everyone can read and write to anytime.

Think of it like...

Imagine a family where parents whisper a secret only to their children (context), versus a community center with a bulletin board where anyone can post or read notes (stores). Context is private and direct; stores are public and accessible.

Svelte Components
┌─────────────┐
│  Parent     │
│  (sets ctx) │
└─────┬───────┘
      │
      ▼
┌─────────────┐
│  Child      │
│ (gets ctx)  │
└─────────────┘

Stores (anywhere in app)
┌─────────────┐
│ Store       │
│ (shared)    │
└─────┬───────┘
      │
┌─────▼───────┐
│ Component A │
└─────────────┘

┌─────────────┐
│ Component B │
└─────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding Svelte component props

Concept: Learn how components pass data using props, the basic way to share data.

In Svelte, you pass data from a parent to a child component using props. For example:

Hello {name}!

Result

The child component shows 'Hello Alice!'. Props flow down from parent to child.

Understanding props is essential because context and stores build on the idea of sharing data between components.

2

Foundation

Introduction to Svelte stores

Concept: Learn what stores are and how they hold reactive shared data.

Stores are special objects that hold data and notify components when data changes. You can import writable from 'svelte/store' to create a store: import { writable } from 'svelte/store'; const count = writable(0); Components can subscribe to this store to reactively get updates.

Result

Components using the store update automatically when the store's value changes.

Stores let you share reactive data across any components without passing props.

3

Intermediate

Using context to pass data down

🤔Before reading on: do you think context can pass data to any component or only direct children? Commit to your answer.

Concept: Context allows a parent to set data that any descendant can access without props.

In a parent component, use setContext to provide data: import { setContext } from 'svelte'; setContext('key', 'secret message'); In a child or deeper descendant, use getContext: import { getContext } from 'svelte'; const message = getContext('key'); This bypasses props and works for any depth.

Result

Descendant components receive the 'secret message' without props.

Context is great for passing data deeply without prop drilling, but only works downward in the component tree.

4

Intermediate

Subscribing to stores in components

🤔Before reading on: do you think stores require manual updates in components or update automatically? Commit to your answer.

Concept: Components can subscribe to stores to reactively update when data changes.

Use the $ prefix to auto-subscribe to stores in Svelte:

Count is {$count}

Result

The displayed count updates automatically when the button is clicked.

The $ prefix makes store usage simple and reactive, improving UI responsiveness.

5

Intermediate

Comparing context and stores use cases

🤔Before reading on: which is better for global app state, context or stores? Commit to your answer.

Concept: Context is for passing data down a component tree; stores are for shared reactive state accessible anywhere.

Context is ideal for passing data tightly coupled to a component subtree, like theming or localization. Stores are better for global or cross-cutting state like user login or counters. Context is not reactive by default; stores are reactive.

Result

You choose context for scoped data and stores for app-wide reactive data.

Knowing when to use context vs stores prevents overcomplicating your app and improves maintainability.

6

Advanced

Making context reactive with stores

🤔Before reading on: can context data update reactively without stores? Commit to your answer.

Concept: You can combine context and stores to pass reactive data down the tree.

Set a store in context: import { writable } from 'svelte/store'; import { setContext, getContext } from 'svelte'; const theme = writable('light'); setContext('theme', theme); Descendants get the store and subscribe: const theme = getContext('theme'); Now context data updates reactively.

Result

Descendants react to theme changes automatically via context and stores.

Combining context with stores gives scoped, reactive data sharing, blending both tools' strengths.

7

Expert

Performance and pitfalls in context vs stores

🤔Before reading on: do you think using many stores or deep context affects performance? Commit to your answer.

Concept: Understanding how context and stores impact rendering and updates helps optimize apps.

Stores notify all subscribers on change, which can cause many re-renders if overused. Context is not reactive alone, so changes require manual triggers or stores. Using many small stores or scoped context reduces unnecessary updates. Beware of overusing context for global state or stores for deeply nested data without scope.

Result

Efficient apps balance context and stores to minimize re-renders and keep code clean.

Knowing internal update mechanics helps avoid performance bottlenecks and bugs in large Svelte apps.

Under the Hood

Context in Svelte uses a key-value map stored in the component tree nodes. When a component calls setContext, it stores data in its node. Descendants call getContext to retrieve data by key, walking up the tree if needed. Stores are reactive objects with subscribe, set, and update methods. When a store's value changes, it calls all subscriber callbacks, triggering component updates.

Why designed this way?

Context was designed to avoid prop drilling, making it easier to pass data deeply without clutter. Stores were created to provide a simple reactive state container usable anywhere, supporting Svelte's reactive UI model. The separation allows scoped data (context) and global reactive state (stores) to coexist cleanly.

Component Tree with Context
┌─────────────┐
│ Parent      │
│ setContext  │
└─────┬───────┘
      │
┌─────▼───────┐
│ Child       │
│ getContext  │
└─────────────┘

Stores Mechanism
┌─────────────┐
│ Store       │
│ (value)     │
│ subscribe() │
└─────┬───────┘
      │
┌─────▼───────┐
│ Subscribers │
│ (components)│
└─────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does context automatically update components when its data changes? Commit to yes or no.

Common Belief: Context data is reactive and updates components automatically like stores.

Reality: Context itself is not reactive; it only passes data once. To have reactive context, you must pass a store inside context.

Why it matters: Assuming context is reactive can cause bugs where UI does not update as expected.

Quick: Can stores replace context in all cases? Commit to yes or no.

Common Belief: Stores can always replace context for data sharing.

Reality: Stores are global and reactive, but context is better for scoped data tied to a component subtree.

Why it matters: Using stores everywhere can lead to unnecessary global state and harder-to-maintain code.

Quick: Is it okay to put all app state in one big store? Commit to yes or no.

Common Belief: One big store for all app state is simpler and better.

Reality: Large stores can cause excessive re-renders and make state management complex; splitting stores or using context for scoped data is better.

Why it matters: Poor store design leads to performance issues and tangled state logic.

Quick: Does getContext work across sibling components? Commit to yes or no.

Common Belief: getContext can get data from any component in the app.

Reality: getContext only accesses data set by ancestors in the component tree, not siblings or unrelated components.

Why it matters: Misusing getContext can cause undefined data errors and confusion about data flow.

Expert Zone

1

Context keys should be unique symbols or strings to avoid collisions, especially in libraries.

2

Stores can be derived or custom with complex logic, enabling powerful reactive patterns beyond simple values.

3

Using context with stores allows creating scoped reactive state that avoids global pollution and improves modularity.

When NOT to use

Avoid using context for global app state that many unrelated components need; use stores instead. Avoid stores for deeply nested, tightly scoped data better handled by context. For very complex state, consider external state management libraries or frameworks.

Production Patterns

In real apps, context is often used for theming, localization, or dependency injection. Stores manage user sessions, form data, or real-time updates. Combining context with stores scopes state to feature modules, improving maintainability and performance.

Connections

Dependency Injection

Context in Svelte acts like dependency injection by providing data to descendants without props.

Understanding context as dependency injection clarifies its role in decoupling components and managing dependencies.

Observer Pattern

Stores implement the observer pattern by notifying subscribers on data changes.

Recognizing stores as observers helps understand their reactive update mechanism and how to design reactive apps.

Shared Memory in Operating Systems

Stores are like shared memory where multiple processes (components) read and write shared data.

This connection highlights challenges like synchronization and update propagation in shared state management.

Common Pitfalls

#1 Trying to update context data directly expecting UI to update.

Wrong approach:

setContext('key', 'value');
// Later change value directly without store
// UI does not update

Correct approach:

import { writable } from 'svelte/store';
const data = writable('value');
setContext('key', data);
// Update with data.set('new value') for reactive updates

Root cause:

Context is not reactive by itself; reactive updates require stores.

#2 Passing data down many levels with props instead of context or stores.

Wrong approach:

Correct approach:

In Grandparent: setContext('name', name);
In Child: const name = getContext('name');

Root cause:

Not knowing context avoids prop drilling leads to verbose and fragile code.

#3 Using one big store for all app state causing performance issues.

Wrong approach:

const appState = writable({ user: {}, theme: 'light', cart: [] });

Correct approach:

const user = writable({});
const theme = writable('light');
const cart = writable([]);

Root cause:

Large stores cause unnecessary re-renders and complex state updates.

Key Takeaways

Context and stores are two distinct ways to share data in Svelte with different scopes and reactivity.

Context passes data down the component tree without props but is not reactive by itself.

Stores hold reactive data accessible anywhere, updating all subscribers automatically.

Combining context with stores enables scoped, reactive data sharing for better app structure.

Choosing between context and stores wisely improves app performance, maintainability, and developer experience.