mirror of
https://github.com/Comfy-Org/ComfyUI_frontend.git
synced 2026-07-15 19:54:32 +00:00
368b5bedd4
## Summary Follow-up cleanups from the reroute chain store work (#13449): deletes the `slot._floatingLinks` mirror in favor of endpoint derivation, fixes two position/endpoint integrity gaps the mirror had masked, and restructures the subgraph-unpack chain stitching. Stacked on #13449. ## Changes - **What**: - `slot._floatingLinks` Sets deleted — a floating link's attachment is fully encoded in its own endpoints, so `slotFloatingLinks(network, side, nodeId, slot)` derives it; ~25 write sites across `addFloatingLink`/`removeFloatingLink`, `setFloatingLinkOrigin`, and every `FloatingRenderLink` connect method are gone - `moveInputLink`/`moveOutputLink` gain the `node` param their `dragNewFrom*` siblings already take - `FloatingRenderLink.connectToSubgraphOutput` now writes the link's **target** end (it wrote `origin_id = SUBGRAPH_OUTPUT_ID`, clobbering/skewing endpoints — masked by the mirror) - `removeInput`/`removeOutput` renumber floating-link slot indices alongside real links (stale indices previously persisted into serialized floating links) - `Reroute.snapToGrid` mirrors into the layout store like `move()` does (Vue hit-testing read a stale spatial index after snapped drags) - Subgraph-unpack reroute chain stitching rewritten as collect-then-stitch (two segment walks + one generic pointer pass, replacing three interleaved walk-and-write loops) ## Review Focus - Scoped out with written assessments: `input.link`/`output.links` mirror removal (roadmap-scale `SlotConnection` extraction, ~530 accesses) and reroute position ownership inversion (layout store only seeds the active graph, no writeback) - Corrupt-data error paths in unpack stitching are normalized to per-link skip (the old code broke the whole loop on some internal-segment failures) --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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 | Merge LiteGraph.js into ComfyUI Frontend | Accepted | 2025-08-05 |
| 0002 | Restructure as a Monorepo | Accepted | 2025-08-25 |
| 0003 | Centralized Layout Management with CRDT | Proposed | 2025-08-27 |
| 0004 | Fork PrimeVue UI Library | Rejected | 2025-08-27 |
| 0005 | Remove Import Map for Vue Extensions | Accepted | 2025-12-13 |
| 0006 | PrimitiveNode Copy/Paste Lifecycle | Proposed | 2026-02-22 |
| 0007 | NodeExecutionOutput Passthrough Schema | Accepted | 2026-03-11 |
| 0008 | Entity Component System | Proposed | 2026-03-23 |
| 0009 | Subgraph Promoted Widgets Use Linked Inputs | Proposed | 2026-05-05 |
| 0010 | Remove Nx Orchestration | Accepted | 2026-05-19 |
Creating a New ADR
- Copy the template below
- Name it with the next number in sequence:
NNNN-descriptive-title.md - Fill in all sections
- Update this index
- Submit as part of your PR
ADR Template
# 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 by Michael Nygard
- Architecture Decision Records - Collection of ADR resources