Custom store logic in Svelte - Deep Dive

Overview - Custom store logic

What is it?

Custom store logic in Svelte means creating your own way to hold and manage data that components can share and react to. Instead of using Svelte's built-in stores directly, you write your own store functions to control how data changes and how components get notified. This helps you build more complex or specific behaviors for your app's data. It is like making your own toolbox for handling shared information.

Why it matters

Without custom store logic, you might struggle to keep your app's data organized and consistent when many parts need to use or change it. Custom stores solve this by letting you define exactly how data updates and who gets told about those updates. This makes your app smoother and easier to maintain, especially as it grows. Without it, apps can become messy, with duplicated data and confusing updates.

Where it fits

Before learning custom store logic, you should understand basic Svelte stores and reactive statements. After mastering custom stores, you can explore advanced state management patterns, context API, and integrating stores with external data sources or APIs.

Mental Model

Core Idea

A custom store is a special object you create that holds data and tells parts of your app when that data changes, letting you control exactly how updates happen.

Think of it like...

Imagine a custom store like a smart mailbox that not only holds letters (data) but also decides who gets notified when a new letter arrives or an old one changes.

┌───────────────┐
│ Custom Store  │
│  ┌─────────┐  │
│  │ Data    │  │
│  └─────────┘  │
│  ┌─────────┐  │
│  │ Subscribe│◄───── Components subscribe here
│  └─────────┘  │
│  ┌─────────┐  │
│  │ Update  │  │
│  └─────────┘  │
└───────┬───────┘
        │
        ▼
  Components react to changes

Build-Up - 7 Steps

1

Foundation

Understanding Svelte's basic stores

Concept: Learn what a store is in Svelte and how it holds reactive data.

Svelte provides simple stores like writable, readable, and derived. A writable store holds a value you can change and lets components react when it updates. You create one with writable(initialValue), then components can subscribe to it or update it with set() or update().

Result

You get a shared value that updates all subscribers automatically when changed.

Understanding basic stores is essential because custom stores build on this idea of shared reactive data.

2

Foundation

How subscriptions work in stores

Concept: Learn how components listen to store changes using subscriptions.

Stores have a subscribe method that components call to get notified when the store's value changes. The subscribe method takes a callback function that runs with the new value. When the component no longer needs updates, it unsubscribes to avoid memory leaks.

Result

Components react instantly and automatically whenever the store's data changes.

Knowing subscriptions lets you design custom stores that control who gets notified and when.

3

Intermediate

Creating a simple custom store

🤔Before reading on: do you think a custom store must always use Svelte's writable internally? Commit to your answer.

Concept: Learn how to write your own store function that returns subscribe, set, and update methods.

A custom store is a function that returns an object with a subscribe method and optionally set and update methods. You can use writable inside or manage your own subscribers and data. For example, you can create a counter store that increments internally and notifies subscribers.

Result

You get a store tailored to your needs, controlling how data changes and notifications happen.

Understanding that stores are just objects with subscribe methods opens the door to fully custom behaviors.

4

Intermediate

Adding custom logic to updates

🤔Before reading on: do you think you can prevent certain updates in a custom store? Commit to yes or no.

Concept: Learn how to add rules or side effects when the store's value changes.

Inside your custom store, you can check new values before setting them, reject invalid changes, or trigger other actions like logging or fetching data. For example, a store might only accept numbers above zero or notify an external service on update.

Result

Your store enforces rules and can do more than just hold data, improving app reliability.

Knowing you can control updates lets you build smarter, safer state management.

5

Intermediate

Managing multiple subscribers manually

Concept: Learn how to track and notify multiple subscribers without writable.

You can keep an array of subscriber functions and call each when data changes. When the first subscriber arrives, you can start background work; when the last leaves, you can stop it. This manual control helps optimize performance and resource use.

Result

Your store efficiently manages subscribers and resources, avoiding unnecessary work.

Understanding manual subscription management helps build stores that scale well in complex apps.

6

Advanced

Creating derived custom stores

🤔Before reading on: do you think derived stores must always use Svelte's derived helper? Commit to yes or no.

Concept: Learn how to build custom stores that compute their value from other stores with custom logic.

A derived store listens to one or more other stores and calculates its value based on them. You can write your own derived store by subscribing to dependencies and updating your value accordingly, adding custom transformations or asynchronous logic.

Result

You get reactive values that automatically update when dependencies change, with full control over computation.

Knowing how to build derived stores manually lets you customize complex data flows beyond built-in helpers.

7

Expert

Optimizing custom stores for performance

🤔Before reading on: do you think notifying subscribers on every set call is always best? Commit to yes or no.

Concept: Learn advanced techniques to reduce unnecessary updates and improve app speed.

You can optimize stores by checking if the new value differs from the old before notifying subscribers, batching multiple updates, or pausing notifications during heavy operations. You can also use weak references or cleanup functions to avoid memory leaks in long-running apps.

Result

Your app runs smoother with fewer wasted renders and better memory use.

Understanding performance tradeoffs in store notifications is key for building scalable, professional apps.

Under the Hood

A Svelte store is an object with a subscribe method that registers callbacks to run when data changes. Internally, stores keep track of subscribers and call them with new values. Custom stores can manage their own subscriber lists and data state, deciding when and how to notify. This works because Svelte components listen to these subscriptions and update their UI reactively when notified.

Why designed this way?

Svelte's store design is minimal and flexible to let developers create simple or complex reactive data flows. The subscribe method standardizes how components listen to changes, while allowing custom stores to add logic or optimize updates. This design avoids heavy frameworks and keeps reactivity explicit and easy to understand.

┌───────────────┐
│ Custom Store  │
│  ┌─────────┐  │
│  │ Data    │  │
│  └─────────┘  │
│  ┌───────────────┐
│  │ Subscribers[] │◄───── List of callback functions
│  └───────────────┘
│  ┌───────────────┐
│  │ subscribe(fn) │─┐
│  └───────────────┘ │
└───────────────┬────┘
                │
                ▼
       Notify all subscribers with new data

Myth Busters - 4 Common Misconceptions

Quick: Do you think custom stores must always use Svelte's writable internally? Commit to yes or no.

Common Belief: Custom stores always wrap Svelte's writable store to work properly.

Reality: Custom stores only need to implement a subscribe method; they can manage data and subscribers entirely on their own without writable.

Why it matters: Believing this limits creativity and leads to unnecessary dependencies, missing opportunities for optimized or specialized stores.

Quick: Do you think all subscribers get notified even if the store's value hasn't changed? Commit to yes or no.

Common Belief: Stores notify subscribers every time set is called, regardless of value changes.

Reality: Well-designed custom stores check if the new value differs before notifying, preventing unnecessary updates and improving performance.

Why it matters: Not checking leads to wasted renders and slower apps, especially with many subscribers.

Quick: Do you think subscriptions automatically stop when components unmount? Commit to yes or no.

Common Belief: Once subscribed, stores keep notifying forever unless manually unsubscribed.

Reality: Svelte automatically unsubscribes when components unmount, but custom stores must correctly return an unsubscribe function to enable this cleanup.

Why it matters: Missing unsubscribe leads to memory leaks and bugs in long-running apps.

Quick: Do you think derived stores always have to be synchronous? Commit to yes or no.

Common Belief: Derived stores must compute their value immediately and synchronously.

Reality: Custom derived stores can handle asynchronous computations and update subscribers when ready.

Why it matters: Knowing this allows building stores that fetch data or perform async tasks reactively.

Expert Zone

1

Custom stores can implement start and stop logic that runs only when the first subscriber arrives and the last leaves, saving resources.

2

You can create stores that expose custom methods beyond subscribe, set, and update, enabling richer APIs for complex state management.

3

Using weak references or careful cleanup in stores prevents subtle memory leaks in apps with dynamic subscriptions.

When NOT to use

Custom store logic is not ideal when your state is simple and fits well with Svelte's built-in writable or derived stores. For very large or complex apps, consider using external state management libraries like Redux or Zustand that offer more features and tooling.

Production Patterns

In real apps, custom stores often manage user sessions, form states with validation, or data caches with expiration. They integrate with APIs to fetch and update data reactively, and sometimes coordinate multiple stores for complex UI states.

Connections

Observer Pattern

Custom stores implement the observer pattern by letting subscribers watch for changes.

Understanding the observer pattern clarifies how stores notify components and why subscribe/unsubscribe methods are essential.

Event Emitters

Custom stores behave like event emitters that send updates to listeners.

Knowing event emitters helps grasp how stores manage multiple subscribers and trigger callbacks.

Publish-Subscribe Messaging (Pub/Sub)

Custom stores follow the pub/sub model where data changes are published and subscribers react.

Recognizing pub/sub patterns aids in designing stores that scale and coordinate complex data flows.

Common Pitfalls

#1 Not returning an unsubscribe function from subscribe.

Wrong approach:

function customStore() {
let value = 0;
let subscribers = [];
return {
subscribe(fn) {
subscribers.push(fn);
fn(value);
// Missing unsubscribe function
},
set(newValue) {
value = newValue;
subscribers.forEach(fn => fn(value));
}
};
}

Correct approach:

function customStore() {
let value = 0;
let subscribers = [];
return {
subscribe(fn) {
subscribers.push(fn);
fn(value);
return () => {
subscribers = subscribers.filter(sub => sub !== fn);
};
},
set(newValue) {
value = newValue;
subscribers.forEach(fn => fn(value));
}
};
}

Root cause:

Learners forget that Svelte relies on the unsubscribe function to clean up subscriptions automatically.

#2 Not checking if new value differs before notifying subscribers.

Wrong approach:

set(newValue) {
value = newValue;
subscribers.forEach(fn => fn(value));
}

Correct approach:

set(newValue) {
if (value !== newValue) {
value = newValue;
subscribers.forEach(fn => fn(value));
}
}

Root cause:

Learners assume every set call must notify, missing performance optimization.

#3 Using synchronous logic only in derived stores.

Wrong approach:

function derivedStore(dep) {
let value;
dep.subscribe(v => {
value = v * 2;
// No async handling
});
return { subscribe: (fn) => fn(value) };
}

Correct approach:

function derivedStore(dep) {
let value;
let subscribers = [];
dep.subscribe(async v => {
const result = await asyncCompute(v);
value = result;
subscribers.forEach(fn => fn(value));
});
return {
subscribe(fn) {
subscribers.push(fn);
fn(value);
return () => {
subscribers = subscribers.filter(sub => sub !== fn);
};
}
};
}

Root cause:

Learners do not consider asynchronous data flows in reactive computations.

Key Takeaways

Custom store logic in Svelte lets you create your own reactive data containers with full control over updates and subscriptions.

Stores are objects with a subscribe method; understanding this minimal interface unlocks powerful custom behaviors.

Managing subscribers manually allows you to optimize performance and resource use in complex apps.

Custom stores can enforce rules, handle async updates, and expose rich APIs beyond simple data holding.

Proper unsubscribe handling and update checks are critical to avoid memory leaks and unnecessary renders.