State Management Solution in Modly: How Zustand Powers the Frontend

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, the application defines navigation state through a strict TypeScript interface:

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 (lines 58-71) selectively stores UI preferences in localStorage:

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: Central application state including backend status, generation jobs, and UI preferences
• navStore.ts: Navigation state tracking the activePage and routing context
• extensionsStore.ts: Extension catalog availability and installation status
• workflowsStore.ts: Workflow definitions, loading mechanisms, and active workflow tracking
• agentStore.ts: Agent-related configuration and operational status
• 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 component in src/shared/components/layout/TopBar.tsx demonstrates this pattern:

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 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. 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 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.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}