State Management

Local state, local stores, and when to reach for a runtime store.

Quick Reference

State location decisions:

Keep UI state in leaf components (default)
Lift state to parent when multiple children need it
Use a local store from createLocalStore for cross-cutting concerns in one bundle (theme, user, org)
Use a runtime store from defineStore for state more than one remote reads or changes
Follow the core-stores skill for which store to call

Avoid:

Prop drilling through 3+ component layers (use a local store instead)
Subscribing to state only used in callbacks (read on-demand)

Local vs Global State

Keep local UI state in leaf components:

Lift state when multiple components need it:

When to use a local store:

State needed across many components (theme, user, org)
State should persist across navigation
Bundle-wide configuration

Local Stores

Use createLocalStore from @prepared911/core/stores/local for state one bundle (one remote or one shell) owns. Call it once at module scope. It generates a reactive hook and a getter per state key, and useStore for any other selector.

With selectors:

The core-stores skill is the rule for this call.

Avoiding Prop Drilling

Don't pass props through 3+ component layers:

When prop drilling is acceptable:

Props passed through 1-2 levels
Props specific to a feature/component tree
Props don't change frequently

Optimization Patterns

Defer State Reads

Don't subscribe to state only used in callbacks—read on-demand:

Lazy State Initialization

Pass a function to useState for expensive initial values:

Use lazy initialization for:

localStorage/sessionStorage reads
Building data structures (indexes, maps)
DOM reads
Heavy transformations

With Prepared patterns:

Writing Hooks - useEffect and custom hooks
Local Storage - localStorage patterns with schema versioning
Re-render Optimization - Advanced optimization patterns

Reference Files

For more detailed technical guidance, see these reference files:

Working on features / Storybook Stories

Working with data / Remote Data

On this page

Quick Reference

Local vs Global State

Local Stores

Avoiding Prop Drilling

Optimization Patterns

Defer State Reads

Lazy State Initialization

State Management

Local state, local stores, and when to reach for a runtime store.

Quick Reference

State location decisions:

Keep UI state in leaf components (default)
Lift state to parent when multiple children need it
Use a local store from createLocalStore for cross-cutting concerns in one bundle (theme, user, org)
Use a runtime store from defineStore for state more than one remote reads or changes
Follow the core-stores skill for which store to call

Avoid: