You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've watched the recent summit, there was a discussion on the granularity of custom nodes that sparked some thoughts. Here is a proposed structured hierarchy to improve clarity and management:
Customer Node: Represents a single, user-interactable entity on the screen.
Node Pack: Handles one specific functionality, for example "load a model" and "apply it", and sometimes "apply (advanced)".
Node Suite: Consists of multiple Node Packs.
This structure will allow ComfyUI-Manager to enable/disable individual nodes/packs after installing a suite, or to install only certain packs instead of the entire suite. Different nodes or packs should be contained in separate files and be easily disabled by renaming.
Additionally, we need to add the concept of "plugins":
Many projects currently categorized as custom nodes should instead be classified as plugins. For instance, ComfyUI-Manager is more accurately described as a plugin. A useful distinction is that a node should operate primarily on the Python backend, allowing the core system to handle rendering. This can help differentiate between plugins and custom node suites.
Given this, creating templates for both custom nodes and plugins would be beneficial.
To investigate the usage of JavaScript, I've reviewed some popular repositories:
These repositories utilize JavaScript extensively for tasks like visualizing outputs (animations/3D objects) and enhancing UI experiences. The former should be implemented as both a custom node suite and a visualization plugin, while the latter should be classified as plugins.
These examples demonstrate that custom nodes can effectively handle tasks without needing JavaScript, providing an example of what pure Python backend nodes look like.
This discussion was converted from issue #3671 on June 10, 2024 18:01.
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I've watched the recent summit, there was a discussion on the granularity of custom nodes that sparked some thoughts. Here is a proposed structured hierarchy to improve clarity and management:
Customer Node: Represents a single, user-interactable entity on the screen.
Node Pack: Handles one specific functionality, for example "load a model" and "apply it", and sometimes "apply (advanced)".
Node Suite: Consists of multiple Node Packs.
This structure will allow ComfyUI-Manager to enable/disable individual nodes/packs after installing a suite, or to install only certain packs instead of the entire suite. Different nodes or packs should be contained in separate files and be easily disabled by renaming.
Additionally, we need to add the concept of "plugins":
Many projects currently categorized as custom nodes should instead be classified as plugins. For instance, ComfyUI-Manager is more accurately described as a plugin. A useful distinction is that a node should operate primarily on the Python backend, allowing the core system to handle rendering. This can help differentiate between plugins and custom node suites.
Given this, creating templates for both custom nodes and plugins would be beneficial.
To investigate the usage of JavaScript, I've reviewed some popular repositories:
Repositories using JavaScript:
These repositories utilize JavaScript extensively for tasks like visualizing outputs (animations/3D objects) and enhancing UI experiences. The former should be implemented as both a custom node suite and a visualization plugin, while the latter should be classified as plugins.
Repositories without JavaScript:
These examples demonstrate that custom nodes can effectively handle tasks without needing JavaScript, providing an example of what pure Python backend nodes look like.
Beta Was this translation helpful? Give feedback.
All reactions