f-flow icon indicating copy to clipboard operation
f-flow copied to clipboard

How to implement type-based connection filtering in userland

Open adrielov opened this issue 8 months ago • 1 comments

Description

"It would be great to have a feature that allows us to limit connection types. For example, an output could have a property like fNodeOutput = ["tool", "input_text"], meaning it could only connect to an fNodeInput with type = "tool". Currently, we have something similar, but it requires specifying a list of node IDs, which isn’t very scalable or practical."


Additional Context

Feature Request: Connection Type Filtering

It would be highly beneficial to introduce a feature that enables type-based connection constraints between nodes.
Currently, connections are limited by explicitly defining a list of node IDs, which becomes impractical as the graph scales.

Proposed Improvement

Allow developers to define accepted connection types using semantic tags. For example:

fNodeOutput = ["tool", "input_text"];

This would restrict connections so that the output can only be linked to nodes with a matching fNodeInput type:

fNodeInput.type = "tool";

Benefits

  • Scalability: Avoids the need to maintain long and dynamic lists of node IDs.
  • Maintainability: Improves readability and manageability of node relationships.
  • Flexibility: Enables more expressive and reusable flow configurations.

adrielov avatar Apr 04 '25 07:04 adrielov

Hi! Thanks a lot for the suggestion.

Currently, Foblex Flow doesn’t support type-based connection filtering out of the box, and I don’t plan to introduce this kind of logic directly into the core API. Adding type restrictions would increase complexity and reduce the flexibility of the library for different use cases.

🔧 Instead, I recommend implementing this logic on the application level — for example, by creating your own type-matching table (e.g., output type → allowed input types) and checking it before allowing a connection. This approach is much more scalable and adaptable to specific project needs.

If, in the future, a clean and universal mechanism emerges that doesn’t complicate the API, I might consider adding it. For now, I believe it’s best handled externally.

Thanks for understanding!

siarheihuzarevich avatar May 01 '25 13:05 siarheihuzarevich