Element

An Element node is the derived form of a widget method: instead of acting on the widget that owns the blueprint, it acts on an element you name explicitly and wire into it. The Self form of the same method takes no target pin and stays in its own widget's category; this category is where every targeted form ends up, whichever widget it came from. You reach for one the moment a graph has to touch something other than itself — a button that clears a text field, an Init graph that lays out three sibling images.

None of them appear in the palette on their own. An Element node is offered only once the graph already holds a binding node for a compatible widget type: an Element literal, or one of the Element Flush / Element Click event heads from Events. Place the binding first.

The category is 123 nodes: the Element reference node at the bottom of this page, and 122 across four more.

• Displayable — geometry, opacity, Variants and property animation, plus the visible and enabled pair eight widget types repeat. 41 nodes.
• Text — nl.text content, typography and effects, and nl.textInput values. 27 nodes.
• List, Slider, Image — list items, selection, scroll position and item fields; slider value and range; image asset, fit mode and crop. 40 nodes.
• Button, Container, Switch, Frame — button label and pointer, container clipping, a Switch's checked state, and the Page a Frame shows. 14 nodes.

Those counts are what the palette offers. A handful of superseded nodes are documented alongside them and marked as hidden; they are not counted, here or on the category table.

Conventions

These hold for every Element node, on this page and the four above.

• The target arrives on a data pin. Displayable, Text, Button, Container, Image and Frame nodes call it element; List nodes use list, Slider nodes use slider, Text Input nodes use textInput. Its valueType is bare element for the Displayable family and element:<widgetType> everywhere else, which is what stops you feeding a Slider into a Text node.
• One palette entry per node type, never one per element. If the graph holds exactly one compatible binding, placing the node wires the target pin to it for you. With two or more the pin is left empty and you pick.
• Same Surface only. An Element literal can only name an element on its own Surface, and the runtime checks again at execution time — a reference whose Surface differs from the executing owner's is rejected. See Surfaces.
• Readers are Pure, writers are Latent. Readers are legal in event, function and macro graphs and may back a Blueprint Value; writers are legal in event and macro only, because they await the host.
• Writes land on the runtime patch layer, not on the authored UI document. A write that actually changes a value queues a flush for the target element; writing the value that is already there does not, and neither do reads or scroll requests.
• Inside a Blueprint Value, a read records what it read. The binding re-evaluates when one of the element properties it actually touched changes, rather than on every flush.

Reference

The one node that is about the wiring itself rather than about a widget's properties.

Element

blueprint.element.ref · Pure

The binding every other Element node waits for. Click the card and Studio switches to the UI editor for the same Surface; pick a non-root element, confirm, and the node stores surfaceId, elementId and elementType before returning you to the blueprint. One Element node can fan out to as many readers and writers as you want.