Hey,
Node attributes are things that are directly present on a GraphNode. You could also call them fields, because a GraphNode like many things in our API has qualities of a DataDictionay, i.e., you can write values over keys into it, just like for Python's own dict.
Such node attributes (for true nodes) are then rendered out quite similarly to port values in the Attribute Manager but they are fundamentally different from ports, as users cannot drive their value with a connection, i.e., the value of a port of another node. And a port also always requires another GraphNode attached to the true node¹ for which they are a port, while the attribute sits directly on the true node.
An attribute, e.g., the name of a node, will also never show up in the node representation in the graph. In the screen below I for example right clicked on the RS Reference node and invoked Add Input > All; but things like Name, Color, Show Preview etc. are alle not listed.
[image: 1744368637847-174097cf-d777-49d2-b0ea-0057c8474a5e-image.png]
That is because they are all attributes and not ports. There is unfortunately no absolute rule like 'everything in Basic is attributes and everything else is ports'. While it holds (for now) true that everything in Basic is an attribute, especially Redshift also puts attributes into other tabs. They usually only appear in more complex scenarios when dealing with port bundles and variadic ports, but they exist.
And just for clarity, attributes do not only exist on nodes that are what our API calls 'true nodes'¹, but also on other GraphNode types, e.g., a GraphNode representing a port. It is just that they are usually not rendered out to the GUI there and more of an internal nature (nodes have a lot of internal attributes).
Cheers,
Ferdinand
¹ GraphNode instances that represent what the end user would consider a 'node', e.g., the RS Reference node, and with that excluding GraphNode instances that for example represent an input port.
