Bind each created node to an instance its parameters live on [minor]

[matt-edmondson]

Fixes #438

The gap

AttributeBasedNodeFactory.CreateNode<T> read the NodeDefinition, extracted the pin display names, and called engine.CreateNode(...). Everything else the definition knew was dropped at that boundary — no T was ever constructed, and no map was kept from a node id back to the definition it came from.

So a tunable declared the way the shipped library declares every one of them — [InputPin] public double Threshold { get; set; } = 128.0; — had nowhere to live, and nothing could answer "which type is this node the user selected". A host wanting an editable threshold had to keep its own parallel dictionary of instances keyed by node id, re-deriving the mapping the factory already had in hand.

The change

CreateNode constructs the type once per node, writes each input pin's declared default onto it, and binds it to the id the engine issued. Three lookups read it back:

GetNodeDefinition(int)	which type this node came from
TryGetNodeInstance(int, out object?)	the object its values live on
GetBinding(int)	both, as a NodeBinding record

PinDefinition.GetValue/SetValue already worked and are unchanged; what was missing was the instance to point them at.

The default written is the attribute's DefaultValue where there is one, otherwise the member's own C# initializer — the same precedence PinDefinition.DefaultValue already reports, so the instance and the pin cannot disagree about the same pin. That is the only reason the write exists: an initializer-derived default is written back unchanged and does nothing.

A method node is deliberately left without an instance. The library already models a non-static method's receiver as an Instance input pin, so one arrives over a link from whichever node produced it. Manufacturing a second here would give the node two receivers that disagree, so TryGetNodeInstance answers false and the definition still resolves. The same answer covers a type with no parameterless constructor.

Why the engine gained two events

A node id only means something while the engine still holds that node, and the engine is the only thing that knows when it stops. NodeRemoved and Cleared are what let the bindings be dropped rather than aged out.

Cleared is not NodeRemoved repeated, and that is the subtle half. Clear() also resets nextNodeId to 1, so the next node created is handed an id a previous node used. Without dropping on Cleared, an unrelated node silently inherits a cleared node's definition and parameter values — which is the failure mode that would be hardest to diagnose from a host, since nothing looks wrong until a value is read.

Testing

Seven tests, 106 → 113, and each one mutation-checked rather than merely watched to pass. Every row is a separate edit to AttributeBasedNodeFactory.cs, run against the full suite:

mutation	failures	caught by
declared default never written (assignability guard inverted)	1	CreateNode_ConstructsAnInstanceCarryingTheDeclaredDefaults
one instance shared by every node of a type	1	CreateNode_GivesEachNodeItsOwnInstance
node removal not observed	1	RemoveNode_DropsTheBinding
clear not observed	1	Clear_DropsEveryBindingSoAReissuedNodeIdIsNotInherited
method node given a manufactured receiver	1	CreateMethodNode_BindsTheDefinitionWithoutManufacturingAReceiver
a created type node never bound at all	5	the four above it, plus GetNodeDefinition_MapsANodeIdBackToTheTypeItCameFrom
unmutated	0	113/113

The Clear test asserts the id really was reissued before asserting the binding did not come with it, so it cannot pass vacuously if that premise ever stops holding.

Verified on Linux, .NET SDK 10.0.401: 113/113 in Debug and Release. NodeGraph.Tests unchanged at 106/106, and ImGui.sln builds clean in Release under the analyzers-as-errors with 0 warnings.

A doc correction

ImGui.NodeEditor/README.md said:

registering a type gives you a node that draws, and nothing here constructs the type or invokes the method

Half of that is now false. It is corrected rather than left to mislead, and the line that still matters is restated where the new behaviour is documented: constructing the type is not executing it, and nothing here calls [NodeExecute]. The parameter-editing round trip is written up alongside it, which is also the concrete answer to #437.

Not included

This is storage and identity, not execution or UI. It does not run a graph, and it does not draw an inspector panel — PinDefinition.DataType is what a host would switch on to pick a widget, and that already exists. #437 asks which of three patterns is intended; this makes the "node properties edited through an inspector panel" one actually implementable, but choosing between them is a maintainer's call rather than something to settle in a PR.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Upt48c89uvSGUWF7Yjx7xk

---

Generated by Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
94.3% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud