At one point, I had the “add nodes” as adornments on incoming nodes but found that there were several key cases in complicated diagrams where the layout didn’t perform the way I ideally wanted.
I had things like node margins come into play but it felt less robust. You can see in this previous post what it used to look like, Tree layout positioning gets messed up.
Having the add nodes as their own node made the layouts cleaner because the add nodes preemptively took up the space where an eventual node would go and GoJS entirely handled positioning. This also made drop zone adornments look cleaner for many cases with less overlapping on other nearby nodes/links because the add node was spaced out enough. Keyboard navigation/interaction is much more straightforward to implement. The biggest advantage may have been the improvement in code readability.
“add nodes” could technically have state. Not yet, but the add node may eventually have a dynamic enabled/disabled state which would also impact styling. It still wouldn’t need to be persisted in the DB though.
I wasn’t aware of unmodeled data at the time I implemented the canvas in question. Can it handle the key cases I am talking about? How would my tree layout handle the positioning of these parts?
The yellow box in Unmodeled Parts section of the Legends and Title link seems to imply that layouts ignore simple parts.