RFC Discussion: rfc:litegraph_native_reroute

[github-actions[bot]]

This is the discussion thread for RFC PR #6.

Please provide feedback and discuss the RFC here rather than in the PR comments.

PR Link: #6

[bezo97]

Use cases where unconnected reroutes provide meaningful functionality

I have a little use case for this that I used multiple times before. I use unconnected reroutes to quickly change active parts of the workflow, like this:

Sort of like a switch. I don't know if there's a better way to do this but that's what I figured out. It's much faster than having to look up the node at the other side of the graph.
That said, I think this is not an intended use case of reroutes and it would be better done some other way. RFC is great 👍

[Nekodificador]

I suggest incorporating a complete logic system into the core, not just regular switches but inverse switches as well. While there are some options available, I usually work with the Impact Pack nodes. Currently, combining inverse switches with regular ones is the only way to simulate a bypass using the API. However, there are broader issues with switches, mainly because some features are only available in specific node packs that are incompatible with others. Adding a logic node family to the core could address many of these problems and enable fully automated workflows.

[JorgeR81]

Let's probably upstream a switch node from rgthree to core to solve this issue?

The rgthree switch relies on the state of the input nodes.
It just passes the input of the first node that's not muted/bypassed.

This "switch" it's intended to be used with Fast Muter nodes, which provide a switch button, at the expense of a bulkier node's graph.

But the main limitation is if we have a switch inside a group.
If we bypass/mute the group, we lose the switch setting ( because the "bypass/mute state" of all nodes in the group it's reseted ).

This is why I use the Impact Pack switch.

[TheToxin-git]

My usage of reroute nodes is somewhat similar; however, I also use them as one-to-many resource providers. This way, when I need to switch / change resources, I only have to change one link instead of many. I can't find a way to recreate this with LiteGraph Native Reroute. Is there a way to connect already spawned node to existing LiteGraph Native Reroute? If so, how to achieve it?

Use cases where unconnected reroutes provide meaningful functionality.

Unconnected use case: I have three Load Checkpoints and three reroutes placed closely to the KSampler in case I need to try another model on this pass. The other two remain unconnected. Reasoning:

It's much faster than having to look up the node at the other side of the graph.

[TheToxin-git]

I also use them as one-to-many resource providers. This way, when I need to switch / change resources, I only have to change one link instead of many.

Example: Let's imagine I have five prompts. For some reason, I want to change the CLIP Skip for all of them.

I can easily do this by placing the "CLIP Set Last Layer" node between "Load Checkpoint" and "Reroute".

How to achieve this using LiteGraph Native Reroute? Can someone show me? I feel that doing this with LGNR will require re-linking every single CLIPTextEncode node.

[JorgeR81]

I also use them as one-to-many resource providers. This way, when I need to switch / change resources, I only have to change one link instead of many.

Example: Let's imagine I have five prompts. For some reason, I want to change the CLIP Skip for all of them.

Ah, yes, I also use "pass" nodes for this type of cases ( #7 (reply in thread) ).

Now that I think about it, these nodes are in all my more complex workflows.

Maybe we could have them in core ComfyUI too, instead of the old reroute ?

• For simple workflows, the new reroute it's more convenient.

• For complex workflows, the "pass" nodes offer more flexibility.

[treeshark12]

I feel Re-routes need to be nameable. Once a workflow becomes complex color coding isn't enough. I might have 6 different conditioning lines. Naming them is very handy (I use the RG 3 ones.) I think the current reroute is fine graphically and a dot is not as good. At present the default reroutes can't be muted. Or put in a group and muted. If you could it would allow for easily making switches.

[JorgeR81]

Yeah, I mostly use "pass" nodes, because they have all the advantages of regular nodes:

• they have a "title" section that can be renamed, like a normal node
• when they are minimized, the wire it's "locked" in place
• they can be muted
• they can be resized ( to make the node's graph look mode symmetric )
• since they have a fixed "type" of input, they usually work better with other custom nodes that accept multiple types of inputs,
  ( e.g "any" switches; use everywhere nodes; universal "bus" nodes ).

I only use reroutes for other data types, that don't have a specific "pass" node ( e.g. FLOAT ).

---

https://github.com/aegis72/aegisflow_utility_nodes

[christian-byrne]

I would like to revisit some aspects of the RFC. Going point-by-point from the Motivation section of the proposal:

• Graph Complexity: The benefit here seems extremely marginal. When looking at the Schema Changes section of the proposal, it also seems that the data is being moved but not necessarily simplified to a meaningful extent.

• Type Safety Issues: The proposal mentions that:

  "The current implementation uses wildcard type matching ("*") for inputs, which bypasses LiteGraph's type checking system. This can lead to type inconsistency issues when connecting nodes, as the reroute node may connect incompatible types without proper validation."

  The old reroutes were not top/any types, they were polymorphic/generic, but still ensured type safety. In fact, for many people it was even too strict (e.g., in the case of FLOAT vs. INT or with input spec config options).

• Type Safety Issues and Implementation Overhead: Even if these are important considerations, I think both of these issues can be sufficiently addressed without necessarily having to rework reroutes

I also would like to question this aspect of the RFC:

The system will maintain support for loading legacy reroute nodes throughout the targeted major version release cycle

It seems the current implementation involves entirely removing old reroutes and using a migration script to convert old reroutes to new reroutes, which does not align with the proposal.

Can we:

• re-evaluate how things have changed given how the implemntation has evolved since the RFC was intiially proposed
• revisit the pros/cons of the current implementation
• re-justify whether old reroutes need to be removed entirely and migrated

[kaalibro]

Not sure if my message about the new reroutes' UX got seen on Discord—might’ve gotten buried in the message storm. Just reposting it here for visibility:

---

First off, I'm not a developer—I'm just a regular user, and everything I say comes from that perspective. Maybe the recent under-the-hood changes are well justified—I wouldn't know. But as an average user, I don't always love them. Case in point: native reroutes. To me, they're pure evil.

What's better now? Well, they're round. Cool. That's about it.
What's worse? Oh, I have plenty to say:

• You can't align them using a keyboard shortcut.

• They're less informative (they indicate data types only by color, which isn't always enough when the workflow already looks like a Christmas tree).

• You can't drag a stack of output links from a reroute to another node.

• You need the precision of a pro gamer just to grab and move them. The cursor doesn't even change to a crosshair when hovering over them! And until you actually start dragging, there's no way to tell if you've aimed correctly.

• Now you have to hold Shift constantly to create a chain of reroutes—and you have to remember to release it when initially dragging a link from a node.

That's a solid 5:0 in favor of the legacy reroutes, at least from a regular user's perspective.

I keep up with the changelogs and sometimes check pull requests, and I've seen you guys put incredible attention into small details. That's awesome! But other times (like now), it feels like a completely different team made this decision :)

Any chance you'd reconsider keeping the legacy reroutes? At least as an option? They're so much more user-friendly than the native ones.

---

UPD: I've read the Motivation section and understand there are some reasons behind the shift to native reroutes. Still, it takes quite a toll on user experience. "Users will need to adapt" kind of sounds like replacing an office chair with a wooden stool for the sake of furniture budget optimization :)

legacy.mp4

native.mp4