# State Management Solution in Modly: How Zustand Powers the Frontend

> Discover how Modly leverages Zustand for efficient frontend state management. Experience type-safe global stores without the Redux boilerplate. Learn more about this powerful solution.

- Repository: [lightningpixel/modly](https://github.com/lightningpixel/modly)
- Tags: deep-dive
- Published: 2026-08-21

---

**Modly implements a lightweight state management solution using Zustand, a hook-based React library that provides type-safe global stores without Redux boilerplate.**

The lightningpixel/modly repository relies on this modern state management solution to coordinate complex UI interactions across its React frontend. By leveraging Zustand's minimal API surface, the codebase maintains performant state updates while keeping bundle size small. All global stores reside in `src/shared/stores/` and follow a consistent pattern of TypeScript interfaces combined with optional persistence middleware.

## Zustand Store Architecture

Modly's implementation centers on the `create` function from the `zustand` package, which generates custom React hooks for each domain-specific store.

### Creating Type-Safe Stores

In [`src/shared/stores/navStore.ts`](https://github.com/lightningpixel/modly/blob/main/src/shared/stores/navStore.ts), the application defines navigation state through a strict TypeScript interface:

```typescript
import { create } from 'zustand'

export interface NavState {
  activePage: string | null
  setActivePage: (page: string | null) => void
}

export const useNavStore = create<NavState>((set) => ({
  activePage: null,
  setActivePage: (page) => set({ activePage: page })
}))

```

This pattern ensures that every store declares its state shape and methods explicitly, providing compile-time safety throughout the state management solution.

### Persistence Middleware Configuration

For settings that must persist between sessions, Modly wraps stores with Zustand's `persist` middleware. The configuration in [`src/shared/stores/appStore.ts`](https://github.com/lightningpixel/modly/blob/main/src/shared/stores/appStore.ts) (lines 58-71) selectively stores UI preferences in `localStorage`:

```typescript
import { create } from 'zustand'
import { persist } from 'zustand/middleware'

export const useAppStore = create<AppState>()(
  persist(
    (set, get) => ({
      // ...state definition...
    }),
    {
      name: 'modly-store',
      partialize: (state) => ({
        generationOptions: state.generationOptions,
        uiScale: state.uiScale,
      })
    }
  )
)

```

The `partialize` option restricts persistence to specific fields, preventing sensitive or transient data from entering `localStorage`.

## Core Store Modules

The frontend organizes state into modular domains under `src/shared/stores/`:

- [`appStore.ts`](https://github.com/lightningpixel/modly/blob/main/appStore.ts): Central application state including backend status, generation jobs, and UI preferences
- [`navStore.ts`](https://github.com/lightningpixel/modly/blob/main/navStore.ts): Navigation state tracking the `activePage` and routing context
- [`extensionsStore.ts`](https://github.com/lightningpixel/modly/blob/main/extensionsStore.ts): Extension catalog availability and installation status
- [`workflowsStore.ts`](https://github.com/lightningpixel/modly/blob/main/workflowsStore.ts): Workflow definitions, loading mechanisms, and active workflow tracking
- [`agentStore.ts`](https://github.com/lightningpixel/modly/blob/main/agentStore.ts): Agent-related configuration and operational status
- [`workflowRunStore.ts`](https://github.com/lightningpixel/modly/blob/main/workflowRunStore.ts): Runtime execution context for active workflow instances

Each module exports a dedicated hook (e.g., `useAppStore`, `useNavStore`) that components import directly.

## Consuming State in Components

Rather than using context providers or prop drilling, components access state through the generated hooks. The [`TopBar.tsx`](https://github.com/lightningpixel/modly/blob/main/TopBar.tsx) component in [`src/shared/components/layout/TopBar.tsx`](https://github.com/lightningpixel/modly/blob/main/src/shared/components/layout/TopBar.tsx) demonstrates this pattern:

```tsx
import { useAppStore } from '@shared/stores/appStore'

function LightSettingsPopover() {
  const { lightSettings, setLightSettings } = useAppStore()
  // Component binds to lightSettings and updates via setLightSettings
}

```

This direct hook consumption eliminates render-prop drilling and ensures components re-render only when their specific slice of state changes.

## Performance Advantages Over Redux

Modly's state management solution avoids the ceremony of action types, reducers, and store configuration required by Redux. The `create` function produces immutable state updates by default while allowing direct mutation syntax in the setter functions. Search results across the codebase confirm zero Redux dependencies, with all state flowing through the Zustand hook pattern established in `src/shared/hooks/*`.

## Summary

- Modly uses **Zustand** exclusively for frontend state management, eliminating Redux boilerplate
- Stores are created via `create` from `zustand` and typed with TypeScript interfaces like `AppState` and `NavState`
- The `persist` middleware in [`src/shared/stores/appStore.ts`](https://github.com/lightningpixel/modly/blob/main/src/shared/stores/appStore.ts) handles `localStorage` persistence for UI preferences
- State is consumed through dedicated hooks (`useAppStore`, `useNavStore`) imported directly by components
- Modular store architecture separates concerns across navigation, workflows, extensions, and agents

## Frequently Asked Questions

### Does Modly use Redux for state management?

No, Modly does not use Redux. The codebase implements a Zustand-based state management solution that provides similar global state capabilities without action types, reducers, or the associated boilerplate. All state interactions occur through Zustand hooks defined in `src/shared/stores/`.

### How does Modly persist user preferences between sessions?

Modly uses Zustand's `persist` middleware configured in [`src/shared/stores/appStore.ts`](https://github.com/lightningpixel/modly/blob/main/src/shared/stores/appStore.ts). This middleware selectively stores fields like `uiScale` and `generationOptions` in browser `localStorage` under the key `modly-store`, while excluding transient or sensitive data through the `partialize` configuration option.

### Are Modly's Zustand stores type-safe?

Yes, every store declares a TypeScript interface describing its complete state shape. For example, [`src/shared/stores/appStore.ts`](https://github.com/lightningpixel/modly/blob/main/src/shared/stores/appStore.ts) defines the `AppState` interface (lines 76-156) that strictly types all state properties and update methods, ensuring compile-time validation across the application's state management solution.

### How many stores does Modly's frontend maintain?

Modly maintains six primary stores in `src/shared/stores/`: `appStore`, `navStore`, `extensionsStore`, `workflowsStore`, `agentStore`, and `workflowRunStore`. This modular approach separates concerns by domain, preventing state collisions and improving maintainability compared to a single monolithic store.