Comfy-Org / Comfy-Org/ComfyUI_frontend
Custom Nodes: Compatibility Legacy / Node 2.0
- Dominant language
- TypeScript
- Stars
- 2k
- Forks
- 699
- Avg merge
- 1d 7h
- Merged PRs (30d)
- 490
Description
First, thank you very much for the great works on ComfyUI.
I'm currently works on my own little toolkit (custom nodes) especially to build a All-In-One workflow for LTX-2 (multi-model, multi-guider, multi-everything ...)
I'm a newbie in this domain but have already done some little good stuff for the high-level user experience (adapted settings node).
But I'm confronted to some difficulty and to be honest, I primarily work in "legacy" mode. However, by enabling "Node 2.0" mode, I realized that my work wasn't necessarily well-suited to the project's evolution.
Ideally, I'd like my nodes to be compatible with both "Node 2.0" and, of course, "legacy" mode.
The following screenshot shows some custom nodes in legacy mode.
And the same in Node 2.0 mode.
Oddly enough, my height calculation problem in my CustomWidget "EXTSTRING," which is supposed to be an improved version of the "STRING" type (multiline: true), is resolved in "Node 2.0" mode. However, since the "check after generate" has become an icon, the node's height is no longer correct.
On the other hand, there are multiple problems in "Node 2.0," such as misaligned links (and even completely out-of-control links between two handles—for example, the connection between the "LTX-2 Model Settings" node and the "MXP Universal Unpacker" node appears offset above the title bar of the "LTX-2 Model Settings" node when I click on the input handle of "MXP Universal Unpacker").
There's also the issue with the draw() function no longer working, and the Bézier curves for my Any switches (1 to N and N to 1) are not working. There's also the "Loading..." which remains stuck in the "aspect_ratio" and "resolution" fields (they're supposed to be dynamically populated from a JSON object), yet it works in "legacy" mode.
Okay, so my nodes are admittedly "exotic." For example, "MXP Universal Unpacker" is a node designed to be used in subgraphs to expand settings that arrive bundled into a single input. It works perfectly in legacy mode.
The "MXP Any Switch" (N to 1) and "MXP Any Switch Inverted" (1 to N) nodes, driven by an index, are dynamic, and the inputs/outputs "appear" as connections are made. I intentionally created a "bridge" with the "MXP Any Switch Index" to force this node as an input to the "driver" handle, thus avoiding ambiguities.
Anyway. I won't go into a long explanation, here's my question.
Given that I want to be compatible with legacy/2.0 and that, as things stand, this seems to pose significant compatibility problems, I have this question: If I work to be compatible with "2.0", will my nodes still function in "legacy" mode? And if so, is there specific documentation to avoid the pitfalls I'm encountering?
If the answer is both yes and no, what is the best approach? I mean, what choice should I make to minimize the need for workarounds in the code for backward compatibility? Should I work in legacy mode or switch to Node 2.0?
Thank you for reading and thank you in advance for your answer. Best regards!
┆Issue is synchronized with this [Notion page](https://www.notion.so/Issue-9340-Custom-Nodes-Compatibility-Legacy-Node-2-0-3176d73d365081b3ba62efd6284ff0d2) by [Unito](https://www.unito.io)
Contributor guide
Assessment
This issue has not been assessed yet.