* Implement subgraph publishing * Add missing null check * Fix subgraph blueprint display in workflows tab * Fix demotion of subgraph blueprints on reload * Update locales [skip ci] * Update blueprint def on save, cleanup * Fix skipped tracking on subgraph publish When a subgraph is first published, it previously was not added to the subgraphCache. This would cause deletion to fail until a reload occurred. * Fix failing vite tests A couple of tests that were mocking classes broke SubgraphBlueprint inheritance. Since they aren't testing anythign related to subgraph blueprints, the subgraph store is mocked as well. * Make blueprint breadcrumb badge clickable * Add confirmation for overwrite on publish * Simplify blueprint badge naming * Swap to promise.allSettled when fetching subgraphs * Navigate into subgraph on blueprint edit * Revert mission of value in blueprint breadcrumb This was causing the blueprint badge to always display * Misc code quality fixes * Set subgraphNode title on blueprint add. When a subgraph blueprint is added to the graph, the title of the subgraphNode is now set to be the title of the blueprint. NOTE: The name of the subgraph node when a blueprint is edited is left unchanged. This may cause minor user confusion. * Add "Delete Blueprint" option to breadcrumb When editing a blueprint, the options provided for the root graph of the breadcrumb included a Delete Workflow option. This still functioned for deleting the current blueprint when selected, but didn't make sense. It has been updated to instead describe that it deletes the current blueprint * Extract subgraph load code as function * Fix subgraphs appearing in library after refresh Subgraph nodes were hidden from the node library and context menu by setting skip_list to true. Unfortunately, this causes them to be mistakenly be caught and registered as vue nodes when a refresh is performed. This is fixed by adding a check for skip_list. * Add delete button and confirmation for deletion * Use more specific warning for blueprint deletion * At success toast on subgraph publish Will return later to potentially add a node library link to the toast * Don't apply subgraph context menu to normal nodes Subgraph blueprints have a right click -> delete option in the node library. This was incorrectly being dislplayed on non blueprint nodes. * Remove hardcoded subgraphs path Rather happy with this change. Rather than trying to introduce a recursive import to pass a magic string, this solution is both sufficient AND allows potential future extensions with less breakage. * Fix nodeDef update on save Wait to update the node def cache until after a blueprint has been saved. Before, changes to links weren't actually being made visisble. * Fix SaveAs with subgraph blueprints * Remove ugly serialize/deserialize Thought I had already tested this, and found that the mere existence of proxies was causing issues, but simply adding a correct annotation is sufficient now. * Improve error specificity * Framework for user defined blueprint descriptions BlueprintDescription can be added to a workflows extra field to provide more useful information about a blueprint's purpose Actually hooking this up in a way that is user accessible is out of scope for right now, but this will simplify future implementation. * Cleanup breadcrumb dropdown options Removes Dupliate for blueprints, adds a publish subgraph option. The publish subgraph button currently routes through the save as logic. Unforunately, this results in the prompt for name referencing workflows. The cleanest way to resolve this is still being considered * Move blueprint renaming into blueprint load Blueprints should automatically set the name of the added node to the filename when added. This mostly worked, but created uglier edgecases: The subgraph itself wasn't renamed, and it would need to be reimplemented to apply when editing a blueprint. Instead, this is now applied when a subgraphBlueprint is first loaded. This keeps all the logic routed through a single point * Move saveAs prompt into workflow class Ensures that the correct publish text is displayed when editing blueprints without making an awful mess of imports * Fix tests by making subgraphBlueprint internal This has the added benefit of forcing better organization. Reverts the useWorkflowThumbnail patch as it is no longer required. * Add tests for subgraph blueprints * Rewrite confirmation dialog * Fix overwrite on publish new subgraph 1 is used as a placeholder size as -1 indicates the baking userFile is temporary, not persisted, and therefore, not able to overwrite when saved. * When editing blueprint, tint background blue * Fix blueprint tint at low LOD * Set node source for blueprints to Blueprint * Fix publish test Making subgraph blueprints non temporary on publish made it so the following load actually occurs. A mock has been added for this load. * Fix multiple nits * Further cleanup: error handling, and comments * Fixing failing test cases This also moves the bg tinting to a property of the workflow, which makes things more extensible in the future. * Fix temporary marking on publish. The prior fix to allow overwrite of an existing blueprint on publish was misguided. By marking a not-yet-loaded file as non-temporary, the load performed prior to saving was actually fetching the file off disk and discarding the existing changes. This additionally entirely prevented publishing when a blueprint did not already exist with the current name. To fix this, the blueprint is not marked as non-temporary until after the load occurs. Note that this load is still required as it initializes the change tracker state required for saving. * Block unloading subgraph blueprints Will need to be revisited if lazy loading is implemented, but this requires solving some ugly sync/async issues. --------- Co-authored-by: github-actions <github-actions@github.com>
Stores
This directory contains Pinia stores for the ComfyUI frontend application. Stores provide centralized state management for the application.
Table of Contents
Overview
Stores in ComfyUI use Pinia, Vue's official state management library. Each store is responsible for managing a specific domain of the application state, such as user data, workflow information, graph state, and UI configuration.
Stores provide a way to maintain global application state that can be accessed from any component, regardless of where those components are in the component hierarchy. This solves the problem of "prop drilling" (passing data down through multiple levels of components) and allows components that aren't directly related to share and modify the same state.
For example, without global state:
App
│
┌──────────┴──────────┐
│ │
HeaderBar Canvas
│ │
│ │
UserMenu NodeProperties
In this structure, if the UserMenu component needs to update something that affects NodeProperties, the data would need to be passed up to App and then down again, through all intermediate components.
With Pinia stores, components can directly access and update the shared state:
┌─────────────────┐
│ │
│ Pinia Stores │
│ │
└───────┬─────────┘
│
│ Accessed by
▼
┌──────────────────────────┐
│ │
│ Components │
│ │
└──────────────────────────┘
Store Architecture
The store architecture in ComfyUI follows these principles:
- Domain-driven: Each store focuses on a specific domain of the application
- Single source of truth: Stores serve as the definitive source for specific data
- Composition: Stores can interact with other stores when needed
- Actions for logic: Business logic is encapsulated in store actions
- Getters for derived state: Computed values are exposed via getters
The following diagram illustrates the store architecture and data flow:
┌─────────────────────────────────────────────────────────┐
│ Vue Components │
│ │
│ ┌───────────────┐ ┌───────────────┐ │
│ │ Component A │ │ Component B │ │
│ └───────┬───────┘ └───────┬───────┘ │
│ │ │ │
└───────────┼────────────────────────────┼────────────────┘
│ │
│ ┌───────────────┐ │
└────►│ Composables │◄─────┘
└───────┬───────┘
│
┌─────────────────────────┼─────────────────────────────┐
│ Pinia Stores │ │
│ │ │
│ ┌───────────────────▼───────────────────────┐ │
│ │ Actions │ │
│ └───────────────────┬───────────────────────┘ │
│ │ │
│ ┌───────────────────▼───────────────────────┐ │
│ │ State │ │
│ └───────────────────┬───────────────────────┘ │
│ │ │
│ ┌───────────────────▼───────────────────────┐ │
│ │ Getters │ │
│ └───────────────────┬───────────────────────┘ │
│ │ │
└─────────────────────────┼─────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ External Services │
│ (API, localStorage, WebSocket, etc.) │
└─────────────────────────────────────────────────────────┘
Core Stores
The following table lists ALL 46 store instances in the system as of 2025-09-01:
Main Stores
| File | Store | Description | Category |
|---|---|---|---|
| aboutPanelStore.ts | useAboutPanelStore | Manages the About panel state and badges | UI |
| apiKeyAuthStore.ts | useApiKeyAuthStore | Handles API key authentication | Auth |
| comfyManagerStore.ts | useComfyManagerStore | Manages ComfyUI application state | Core |
| comfyManagerStore.ts | useManagerProgressDialogStore | Manages manager progress dialog state | UI |
| comfyRegistryStore.ts | useComfyRegistryStore | Handles extensions registry | Registry |
| commandStore.ts | useCommandStore | Manages commands and command execution | Core |
| dialogStore.ts | useDialogStore | Controls dialog/modal display and state | UI |
| domWidgetStore.ts | useDomWidgetStore | Manages DOM widget state | Widgets |
| electronDownloadStore.ts | useElectronDownloadStore | Handles Electron-specific download operations | Platform |
| executionStore.ts | useExecutionStore | Tracks workflow execution state | Execution |
| extensionStore.ts | useExtensionStore | Manages extension registration and state | Extensions |
| firebaseAuthStore.ts | useFirebaseAuthStore | Handles Firebase authentication | Auth |
| graphStore.ts | useTitleEditorStore | Manages title editing for nodes and groups | UI |
| graphStore.ts | useCanvasStore | Manages the graph canvas state and interactions | Core |
| helpCenterStore.ts | useHelpCenterStore | Manages help center visibility and state | UI |
| imagePreviewStore.ts | useNodeOutputStore | Manages node outputs and execution results | Media |
| keybindingStore.ts | useKeybindingStore | Manages keyboard shortcuts | Input |
| maintenanceTaskStore.ts | useMaintenanceTaskStore | Handles system maintenance tasks | System |
| menuItemStore.ts | useMenuItemStore | Handles menu items and their state | UI |
| modelStore.ts | useModelStore | Manages AI models information | Models |
| modelToNodeStore.ts | useModelToNodeStore | Maps models to compatible nodes | Models |
| nodeBookmarkStore.ts | useNodeBookmarkStore | Manages node bookmarks and favorites | Nodes |
| nodeDefStore.ts | useNodeDefStore | Manages node definitions and schemas | Nodes |
| nodeDefStore.ts | useNodeFrequencyStore | Tracks node usage frequency | Nodes |
| queueStore.ts | useQueueStore | Manages execution queue and task history | Execution |
| queueStore.ts | useQueuePendingTaskCountStore | Tracks pending task counts | Execution |
| queueStore.ts | useQueueSettingsStore | Manages queue execution settings | Execution |
| releaseStore.ts | useReleaseStore | Manages application release information | System |
| serverConfigStore.ts | useServerConfigStore | Handles server configuration | Config |
| settingStore.ts | useSettingStore | Manages application settings | Config |
| subgraphNavigationStore.ts | useSubgraphNavigationStore | Handles subgraph navigation state | Navigation |
| systemStatsStore.ts | useSystemStatsStore | Tracks system performance statistics | System |
| toastStore.ts | useToastStore | Manages toast notifications | UI |
| userFileStore.ts | useUserFileStore | Manages user file operations | Files |
| userStore.ts | useUserStore | Manages user data and preferences | User |
| versionCompatibilityStore.ts | useVersionCompatibilityStore | Manages frontend/backend version compatibility warnings | Core |
| widgetStore.ts | useWidgetStore | Manages widget configurations | Widgets |
| workflowStore.ts | useWorkflowStore | Handles workflow data and operations | Workflows |
| workflowStore.ts | useWorkflowBookmarkStore | Manages workflow bookmarks and favorites | Workflows |
| workflowTemplatesStore.ts | useWorkflowTemplatesStore | Manages workflow templates | Workflows |
| workspaceStore.ts | useWorkspaceStore | Manages overall workspace state | Workspace |
Workspace Stores
Located in stores/workspace/:
| File | Store | Description | Category |
|---|---|---|---|
| bottomPanelStore.ts | useBottomPanelStore | Controls bottom panel visibility and state | UI |
| colorPaletteStore.ts | useColorPaletteStore | Manages color palette configurations | UI |
| nodeHelpStore.ts | useNodeHelpStore | Handles node help and documentation display | UI |
| searchBoxStore.ts | useSearchBoxStore | Manages search box functionality | UI |
| sidebarTabStore.ts | useSidebarTabStore | Controls sidebar tab states and navigation | UI |
Store Development Guidelines
When developing or modifying stores, follow these best practices:
- Define clear purpose: Each store should have a specific responsibility
- Use actions for async operations: Encapsulate asynchronous logic in actions
- Keep stores focused: Each store should manage related state
- Document public API: Add comments for state properties, actions, and getters
- Use getters for derived state: Compute derived values using getters
- Test store functionality: Write unit tests for stores
Store Template
Here's a template for creating a new Pinia store, following the setup style used in ComfyUI:
import { defineStore } from 'pinia'
import { computed, ref } from 'vue'
export const useExampleStore = defineStore('example', () => {
// State
const items = ref([])
const isLoading = ref(false)
const error = ref(null)
// Getters
const itemCount = computed(() => items.value.length)
const hasError = computed(() => error.value !== null)
// Actions
function addItem(item) {
items.value.push(item)
}
async function fetchItems() {
isLoading.value = true
error.value = null
try {
const response = await fetch('/api/items')
const data = await response.json()
items.value = data
} catch (err) {
error.value = err.message
} finally {
isLoading.value = false
}
}
// Expose state, getters, and actions
return {
// State
items,
isLoading,
error,
// Getters
itemCount,
hasError,
// Actions
addItem,
fetchItems
}
})
Common Patterns
Stores in ComfyUI frequently use these patterns:
API Integration
import { defineStore } from 'pinia'
import { ref } from 'vue'
import { api } from '@/scripts/api'
export const useDataStore = defineStore('data', () => {
const data = ref([])
const loading = ref(false)
const error = ref(null)
async function fetchData() {
loading.value = true
try {
const result = await api.getExtensions()
data.value = result
} catch (err) {
error.value = err.message
} finally {
loading.value = false
}
}
return {
data,
loading,
error,
fetchData
}
})
Store Composition
import { defineStore, storeToRefs } from 'pinia'
import { computed, ref, watch } from 'vue'
import { useOtherStore } from './otherStore'
export const useComposedStore = defineStore('composed', () => {
const otherStore = useOtherStore()
const { someData } = storeToRefs(otherStore)
// Local state
const localState = ref(0)
// Computed value based on other store
const derivedValue = computed(() => {
return computeFromOtherData(someData.value, localState.value)
})
// Action that uses another store
async function complexAction() {
await otherStore.someAction()
localState.value += 1
}
return {
localState,
derivedValue,
complexAction
}
})
Persistent State
import { defineStore } from 'pinia'
import { ref, watch } from 'vue'
export const usePreferencesStore = defineStore('preferences', () => {
// Load from localStorage if available
const theme = ref(localStorage.getItem('theme') || 'light')
const fontSize = ref(parseInt(localStorage.getItem('fontSize') || '14'))
// Save to localStorage when changed
watch(theme, (newTheme) => {
localStorage.setItem('theme', newTheme)
})
watch(fontSize, (newSize) => {
localStorage.setItem('fontSize', newSize.toString())
})
function setTheme(newTheme) {
theme.value = newTheme
}
return {
theme,
fontSize,
setTheme
}
})
Testing Stores
Stores should be tested to ensure they behave as expected. Here's an example of how to test a store:
import { createPinia, setActivePinia } from 'pinia'
import { beforeEach, describe, expect, it, vi } from 'vitest'
import { nextTick } from 'vue'
import { api } from '@/scripts/api'
import { useExampleStore } from '@/stores/exampleStore'
// Mock API dependencies
vi.mock('@/scripts/api', () => ({
api: {
getData: vi.fn()
}
}))
describe('useExampleStore', () => {
let store: ReturnType<typeof useExampleStore>
beforeEach(() => {
// Create a fresh pinia instance and make it active
setActivePinia(createPinia())
store = useExampleStore()
// Clear all mocks
vi.clearAllMocks()
})
it('should initialize with default state', () => {
expect(store.items).toEqual([])
expect(store.isLoading).toBe(false)
expect(store.error).toBeNull()
})
it('should add an item', () => {
store.addItem('test')
expect(store.items).toEqual(['test'])
expect(store.itemCount).toBe(1)
})
it('should fetch items', async () => {
// Setup mock response
vi.mocked(api.getData).mockResolvedValue(['item1', 'item2'])
// Call the action
await store.fetchItems()
// Verify state changes
expect(store.isLoading).toBe(false)
expect(store.items).toEqual(['item1', 'item2'])
expect(store.error).toBeNull()
})
})
For more information on Pinia, refer to the Pinia documentation.