svelte-store-management

This repository demonstrates different approaches for state management in SvelteKit applications. Each variant shows different patterns and trade-offs for managing application state.

1. Load Variant (01-load-variant)

This approach uses SvelteKit's load function with dependency tracking and invalidation.

Advantages:

• Clean separation between data fetching and presentation
• Built-in dependency tracking with depends() and invalidate()
• Server-side rendering support out of the box
• No additional state management libraries needed
• Works well with SvelteKit's data flow patterns

Disadvantages:

• Requires full page/component reload on data changes
• Less granular control over state updates
• Can cause unnecessary re-fetching of data
• Callbacks need to be passed down through props
• No optimistic updates without additional logic

2. Load Bastard Variant (02-load-bastard-variant)

A hybrid approach that fetches data via load function but manages local state with $state rune.

Advantages:

• Initial data from server with SSR support
• Local state management for immediate UI updates
• Optimistic updates possible
• No need for invalidation on every change
• Better performance for frequent updates

Disadvantages:

• State can diverge from server data
• Manual synchronization required between local and server state
• Props drilling for callbacks (onAdded, onDeleted)
• Mixing patterns can be confusing
• Potential for inconsistencies if not carefully managed

3. Store Variant (03-store-variant)

Uses Svelte stores created in the load function with custom methods for state management.

Advantages:

• Encapsulated state logic in store
• Methods co-located with data
• Reactive updates via store subscriptions
• Can implement optimistic updates
• Better separation of concerns

Disadvantages:

• Store creation on every load
• Not shareable across routes
• More complex setup than simple load functions
• Need to manage store lifecycle
• Props drilling for store reference

4. Store Context Variant (04-store-context-variant)

Combines stores with Svelte's context API for better component communication.

Advantages:

• No props drilling - access store via context
• Clean component interfaces
• Centralized state management
• Better component reusability
• Maintains store benefits (reactivity, encapsulation)

Disadvantages:

• Requires layout wrapper for context provider
• More boilerplate code
• Context must be set up correctly in component hierarchy
• Store still recreated on navigation
• Can be harder to test components in isolation

5. Universal Reactivity Variant (05-universal-reactivity-variant)

Uses Svelte 5's universal reactivity with $state rune in a separate module.

Advantages:

• Simple, modern syntax with $state rune
• Module-level state persists across navigations
• Direct function exports for actions
• No context or store subscriptions needed
• Very clean component code

Disadvantages:

• Global singleton state (not isolated per request)
• No SSR - state starts empty on client
• Can cause issues with multiple users/tabs
• Harder to reset state
• Testing requires careful state cleanup

6. Universal Reactivity with Global State (06-universal-reactivity-variant-with-global-state)

Enhanced universal reactivity pattern with structured global state object.

Advantages:

• Organized global state structure
• Type-safe state interface
• Centralized state management
• Easy to extend with more state properties
• Direct access from any component

Disadvantages:

• Same SSR limitations as variant 5
• Global singleton issues persist
• Requires discipline to avoid coupling
• Can become a "god object" anti-pattern if not careful