[Proposal] Make node property validation tooltip more understandable

If node’s property validation fails, the node will be flagged with an error. The details of the error can be checked with the tooltip of the node. But, it may not be meaningful to the user in some case because the information in the tooltip is internal property name.

スクリーンショット 2022-01-15 0.05.04

So, I would like to propose a message to be displayed in the tooltip can be specified within the property definition.

Proposal:

  • A property definitions can have a validationMessage property. If the property validation fails, the value of the validationMessage property is displayed instead of property name in node's tooltip.

Example:
op1: {value:"1": validate:RED.validators.typedInput("op1type"), validationMessage:"Invalid send data"}

4 Likes

@nisiyama,
I like the proposal!

But a single field can contain lots of data. For example an array of objects that are being displayed inside an editableList. Such data can be wrong due to multiple different reasons: duplicate names, more than 10 rows, or whatever.

In this case it might be usefull if we were able to show the particular error, which means the validationMessage should refer to a callback function (that generates a validation message). On the other hand perhaps not, because then you would have to repeat your entire validation logic in that second function again.

So perhaps that is a really bad idea, and your static text is indeed much better...
Bart

Hi @nisiyama

If instead of validationMessage, the property had a friendlyName property e.g...

op1: {
  value:"1": 
  validate:RED.validators.typedInput("op1type"), 
  friendlyName:"send data"
}

This would be useful in other areas too. e.g. for field tooltips, form labels, friendlier debug messages, automation (and many more places I cannot think of right now).

Then the nodes triangle tip could be a concatenation of " - Invalid " + op1.friendlyName

We also have this item to allow a node to provide a validate function that isn't tied to a specific property - as sometimes the validation has to be done by considering the overall configuration and not one property at a time.

The question is then how to provide better feedback to the user when the validation fails (as highlighted in this item on the backlog

Some comments on the ideas proposed so far:

  1. validationMessage: "a message"
    If there are multiple reasons why a value could be invalid, a single message won't help the user understand what is wrong.
  2. validationMessage: function() {}
    This would allow for more flexible messages - but it would require duplicate code to work out what value to return
  3. friendlyName
    For this use case, it wouldn't help communicate what was wrong with the value. There may well be other usability improvements that such a field would bring, but I would suggest not entangling them here.

What I think I had in mind for this area was actually to modify the existing validate property.

Currently it returns true or false based on whether the field is valid.

We could extend that to:

  • return true - valid (as-is behaviour)
  • return false - invalid (as-is behaviour)
  • return "string" - invalid with given error message

The downside is backward compatibility - installing a newer node in old Node-RED and having the validate function return a string that looks like true when it actually means false

So another option would be for the validate function to throw an error with the message in. The existing Node-RED code already catches the error and logs it in the browser console:

if (valid && "validate" in definition[property]) {
            try {
                valid = definition[property].validate.call(node,value);
            } catch(err) {
                console.log("Validation error:",node.type,node.id,"property: "+property,"value:",value,err);
            }
        }

That could be modified to also set valid to false if an error is thrown and to capture the message from the error for reporting back to the user.

Could that be made to work if the message included variables? Could the message access a variable from the validation function? Or perhaps better (but more complex), could additional properties be allowed on the defaults property that were accessible from within the validation function?

Agree though maybe for a slightly different reason. I think that having the simple boolean response is nice and clean from a development perspective.

Sounds usable though more complex from a usability perspective maybe(?) than properties on the default? Quite probably simpler from a core development perspective though?

I disagree. I don't think you can call throw new Error("only cats allowed") is more complex then return false for anyone with even passing experience writing JavaScript code.

It feels quite a natural way for a function to "fail" with an associated message.

I'm not sure a simple string would be suitable... it would need to be translate-able for other locales at least wouldn't it ?

A message catalogue identifier is a string. We'd do the same thing we do elsewhere - check for a message in the node's catalog, or fall back to the string as is.

Thank you for comments on the proposal, everyone.

I have a concern that exception approach also have a compatibility issue when a newer node is used on existing Node-RED because throwing Error only display the message on browser console.

From a flexibility point of view, I think it's a good idea to change the API of the validate function as you suggested. However, I think it may be necessary to use the old and new API properly with an additional argument to validator. In that case, I prefer the idea returning the message string.

For simple cases, it would be nice to be able to specify an additional message string to RED.validators functions.

validate: RED.validators.typedInput("op1type", "Invalid send data")