Add support of typeField property validation message

[GogoVega]

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)

Proposed changes

This PR is an extension of #4449 and was discussed inside.

If an input is builded with typedInput and contains the typeField option:

$("#node-input-path").typedInput({
    default: "str",
    typeField: "#node-input-pathType",
    types: ["str", "msg"],
});

and node properties contains a validator for typeField:

defaults: {
    path: {
        value: "",
        ...
    },
    pathType: {
        value: "str",
        validate: RED.validators.regex(/^str$/),
        ...
    }, ...
}

This PR adds a validation tooltip message to the field if the typeField validation is not correct.

In the example, validation only accepts the type str not msg:

Note: the message on the screenshot is not the message that the example should produce

Checklist

• I have read the contribution guidelines
• For non-bugfix PRs, I have discussed this change on the forum/slack team.
• I have run npm run test to verify the unit tests pass
• I have added suitable unit tests to cover the new/changed functionality

[knolleary]

Whilst this works for 'top level' properties, it doesn't automatically apply to general usage of TypedInput. For example, in a switch node, I get the tooltop in the top TypedInput, but not one embedded inside the rules property.

The typedInput already does validation on itself, so this feature may be better served by adding it to TypedInput itself. This would lose the ability to do custom validation on the Type field, but I'm not sure how common a use case that is compared to better feedback on general TypedInput errors.

[GogoVega]

I'm going to check that 🤔

[GogoVega]

So... yes, I also worked on the non "top-level" part here but I haven't created a PR yet.

PS: To see if we keep the "prettier" modifications?

PPS: I believe there remains this question. I will check the content for this weekend 😉

[GogoVega]

Regarding your second question, typedInput has an internal validator but it is not directly linked to node validation.

If typedInput uses its default validators, only a custom validation (Regex rules for example) in the node will add an error to the field. In the other case, the node validation will retrieve the result from typedInput.

I grant you that we do the job twice for the "top" elements but these elements can be defined differently - the "safest" behavior (in the sense of validating the node) being to validate it on both sides.

[GogoVega]

Ok, I added a rule that lets validate by typedInput if there is no node validation for the property.