mirror of
https://github.com/Comfy-Org/ComfyUI_frontend.git
synced 2026-05-04 05:02:17 +00:00
3e197b5c57
## Summary
Architecture documentation proposing an Entity Component System for the
litegraph layer.
```mermaid
graph LR
subgraph Today["Today: Spaghetti"]
God["🍝 God Objects"]
Circ["🔄 Circular Deps"]
Mut["💥 Render Mutations"]
end
subgraph Tomorrow["Tomorrow: ECS"]
ID["🏷️ Branded IDs"]
Comp["📦 Components"]
Sys["⚙️ Systems"]
World["🌍 World"]
end
God -->|"decompose"| Comp
Circ -->|"flatten"| ID
Mut -->|"separate"| Sys
Comp --> World
ID --> World
Sys -->|"query"| World
```
## Changes
- **What**: ADR 0008 + 4 architecture docs (no code changes)
- `docs/adr/0008-entity-component-system.md` — entity taxonomy, branded
IDs, component decomposition, migration strategy
- `docs/architecture/entity-interactions.md` — as-is Mermaid diagrams of
all entity relationships
- `docs/architecture/entity-problems.md` — structural problems with
file:line evidence
- `docs/architecture/ecs-target-architecture.md` — target architecture
diagrams
- `docs/architecture/proto-ecs-stores.md` — analysis of existing Pinia
stores as proto-ECS patterns
## Review Focus
- Does the entity taxonomy (Node, Link, Subgraph, Widget, Slot, Reroute,
Group) cover all cases?
- Are the component decompositions reasonable starting points?
- Is the migration strategy (bridge layer, incremental extraction)
feasible?
- Are there entity interactions or problems we missed?
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-10420-docs-ADR-0008-Entity-Component-System-32d6d73d365081feb048d16a5231d350)
by [Unito](https://www.unito.io)
---------
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-authored-by: GitHub Action <action@github.com>
Co-authored-by: Amp <amp@ampcode.com>
Co-authored-by: Christian Byrne <cbyrne@comfy.org>
87 lines
3.2 KiB
Markdown
87 lines
3.2 KiB
Markdown
# Architecture Decision Records
|
|
|
|
This directory contains Architecture Decision Records (ADRs) for the ComfyUI Frontend project.
|
|
|
|
## What is an ADR?
|
|
|
|
An Architecture Decision Record captures an important architectural decision made along with its context and consequences. ADRs help future developers understand why certain decisions were made and provide a historical record of the project's evolution.
|
|
|
|
## ADR Index
|
|
|
|
| ADR | Title | Status | Date |
|
|
| -------------------------------------------------------- | ---------------------------------------- | -------- | ---------- |
|
|
| [0001](0001-merge-litegraph-into-frontend.md) | Merge LiteGraph.js into ComfyUI Frontend | Accepted | 2025-08-05 |
|
|
| [0002](0002-monorepo-conversion.md) | Restructure as a Monorepo | Accepted | 2025-08-25 |
|
|
| [0003](0003-crdt-based-layout-system.md) | Centralized Layout Management with CRDT | Proposed | 2025-08-27 |
|
|
| [0004](0004-fork-primevue-ui-library.md) | Fork PrimeVue UI Library | Rejected | 2025-08-27 |
|
|
| [0005](0005-remove-importmap-for-vue-extensions.md) | Remove Import Map for Vue Extensions | Accepted | 2025-12-13 |
|
|
| [0006](0006-primitive-node-copy-paste-lifecycle.md) | PrimitiveNode Copy/Paste Lifecycle | Proposed | 2026-02-22 |
|
|
| [0007](0007-node-execution-output-passthrough-schema.md) | NodeExecutionOutput Passthrough Schema | Accepted | 2026-03-11 |
|
|
| [0008](0008-entity-component-system.md) | Entity Component System | Proposed | 2026-03-23 |
|
|
|
|
## Creating a New ADR
|
|
|
|
1. Copy the template below
|
|
2. Name it with the next number in sequence: `NNNN-descriptive-title.md`
|
|
3. Fill in all sections
|
|
4. Update this index
|
|
5. Submit as part of your PR
|
|
|
|
## ADR Template
|
|
|
|
```markdown
|
|
# N. Title
|
|
|
|
Date: YYYY-MM-DD
|
|
|
|
## Status
|
|
|
|
[Proposed | Accepted | Rejected | Deprecated | Superseded by [ADR-NNNN](NNNN-title.md)]
|
|
|
|
## Context
|
|
|
|
Describe the issue that motivated this decision and any context that influences or constrains the decision.
|
|
|
|
- What is the problem?
|
|
- Why does it need to be solved?
|
|
- What forces are at play (technical, business, team)?
|
|
|
|
## Decision
|
|
|
|
Describe the decision that was made and the key points that led to it.
|
|
|
|
- What are we going to do?
|
|
- How will we do it?
|
|
- What alternatives were considered?
|
|
|
|
## Consequences
|
|
|
|
### Positive
|
|
|
|
- What becomes easier or better?
|
|
- What opportunities does this create?
|
|
|
|
### Negative
|
|
|
|
- What becomes harder or worse?
|
|
- What risks are we accepting?
|
|
- What technical debt might we incur?
|
|
|
|
## Notes
|
|
|
|
Optional section for additional information, references, or clarifications.
|
|
```
|
|
|
|
## ADR Status Values
|
|
|
|
- **Proposed**: The decision is being discussed
|
|
- **Accepted**: The decision has been agreed upon
|
|
- **Rejected**: The decision was not accepted
|
|
- **Deprecated**: The decision is no longer relevant
|
|
- **Superseded**: The decision has been replaced by another ADR
|
|
|
|
## Further Reading
|
|
|
|
- [Documenting Architecture Decisions](https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions) by Michael Nygard
|
|
- [Architecture Decision Records](https://adr.github.io/) - Collection of ADR resources
|