Purpose

When a user creates a input node (also known as a symbol node) in a custom node workspace previously the input node was empty. If left in this state and saved, the input symbol would be invalid as it did not have a default name, and would raise a warning and disallow save when next opened.

Just for the curious the input does have a default type though (var[]..[]).

To address this issue - now when an Input node is constructed now we set the name to a default (I'm just using input for now, which is what we use as a display name when the name is empty)
We now also show the type hint in default string to make the syntax more discoverable, as well as a comment - we could also show the default value syntax easily enough but I thought that might be info overload, as well as potentially having unintended consequences.

before:

after:

Declarations

Check these if you believe they are true

• The codebase is in a better state after this PR
• Is documented according to the standards
• The level of testing this PR includes is appropriate
• User facing strings, if any, are extracted into *.resx files
• All tests pass using the self-service CI.
• Snapshot of UI changes, if any.
• Changes to the API follow Semantic Versioning and are documented in the API Changes document.
• This PR modifies some build requirements and the readme is updated
• This PR contains no files larger than 50 MB

Release Notes

By default creating inputs in a custom node will not put the custom node into an invalid state.

Reviewers

(FILL ME IN) Reviewer 1 (If possible, assign the Reviewer for the PR)

(FILL ME IN, optional) Any additional notes to reviewers or testers.

FYIs

@Jingyi-Wen thoughts on this approach or what the default name / default string should be?