leptos-store
Enterprise-grade, type-enforced state management for Leptos
Overview
leptos-store provides a structured, SSR-safe state management architecture for Leptos, inspired by Vuex and Pinia, translated into idiomatic Rust.
Leptos provides excellent primitives (signals, context, resources), but no canonical, scalable state architecture. This creates problems for large teams, enterprise governance, long-lived applications, SSR correctness, and auditing.
leptos-store exists to solve structure, not reactivity.
Features
- 🏗️ Global, namespaced stores - Clear domain boundaries
- 🔒 Predictable mutation flow - Only mutators can write state
- 🌐 First-class SSR support - Works seamlessly with server-side rendering
- ⚡ Async-safe actions - Built-in support for async operations
- 🔧 Compile-time enforcement - Catch errors at compile time, not runtime
- 📦 Zero magic - No hidden executors or runtime reflection
Installation
Add to your Cargo.toml:
[]
= "0.1"
= "0.8"
Quick Start
Define Your Store
use *;
use *;
// Define your state
// Define your store
Use in Components
Using the store! Macro
For less boilerplate, use the declarative macro:
use store;
store!
Available Macros
| Macro | Purpose |
|---|---|
define_state! |
Define state structs with default values |
define_action! |
Define synchronous action structs |
define_async_action! |
Define async action structs with result types |
impl_store! |
Implement Store trait for an existing type |
store! |
Complete store definition in one macro |
define_state! - State with Defaults
use define_state;
define_state!
let user = default;
assert_eq!;
assert!;
define_action! - Synchronous Actions
use define_action;
define_action!
let action = new;
define_async_action! - Async Actions with Error Types
use define_async_action;
// Define your error type
// Define the async action
define_async_action!
let action = new;
// Helper methods for documentation
assert!;
assert_eq!;
assert_eq!;
impl_store! - Quick Store Trait Implementation
use *;
use ;
// One-liner to implement Store trait
impl_store!;
Conceptual Model
Each store is a domain module composed of:
| Layer | Description | Can Write State | Async | Side Effects |
|---|---|---|---|---|
| State | Read-only externally | N/A | ❌ | ❌ |
| Getters | Derived, read-only | ❌ | ❌ | ❌ |
| Mutators | Pure, synchronous writes | ✅ | ❌ | ❌ |
| Actions | Sync orchestration | ❌ | ❌ | ✅ |
| Async Actions | Async orchestration | ❌ | ✅ | ✅ |
Only mutators may write state. This is the core principle that ensures predictability.
Advanced Usage
Async Actions
use *;
Scoped Stores
For multiple instances of the same store type:
// Provide scoped stores with unique IDs
;
;
// Access scoped stores
let counter1 = ;
let counter2 = ;
Store Registry
For debugging and hot-reloading:
let mut registry = new;
registry.register?;
// Later...
let store = registry.;
Design Philosophy
Convention over Primitives
Instead of giving you raw signals and hoping for the best, leptos-store provides a structured architecture that scales.
Compile-time Enforcement
The type system prevents invalid state transitions. If it compiles, it follows the rules.
SSR-First Design
Every feature is designed with server-side rendering in mind. No hydration mismatches.
Examples
See the examples/ directory for complete examples:
auth-store-example- User authentication flow with login/logout
Contributing
We welcome contributions! See AUTHORING.md for:
- Development setup and workflow
- Project structure and architecture
- Testing and code quality guidelines
- Publishing releases
# Quick start for contributors
License
MIT OR Apache-2.0