How can I block closing the form panel unless the user clicked on Done,Cancel or Delete buttons?

[AllanOricil]

I need a reliable solution that doesn’t allow closing the node form when there are errors. At the moment I was able to partially accomplish this disabling the “Done” button. However, this solution doesn’t fully work because the form closes whenever the User clicks outside of it and the changes are applied to the node, even with errors.

These node changes must not be saved in the client if there are errors. If the User attempts to save his changes to the node form, I want to run my custom validation (which is based on json schema) and block the client updates if the validation returns erros. This has to work even if the User uses shortcuts.

[Steve-Mcl]

The current UX is as follows.

1. User closes the edit form (however that occurs)
2. If there are errors, a badge is applied to the node
3. If the user attempts to deploy, they are made aware of node configuration errors.
4. User can simply open the "bad node" and fix it.

Applying any workarounds or hacks to prevent the current standard operation will likely not age well (if/when the editor logic is changed in the core)

---

EDIT:

I am not saying we couldn't / shouldn't have a means of preventing form dismissal just that there is not currently a standard means of doing so.

If you have a concrete proposal, please do make it & we can all evaluate.

That might be adding a new hook - something like onclose to the API e,g...

definition.onclose = function(reason) {
    if (reason === 'cancel') {
        return true // user is cancelling, just let it close.
    }
    return isValid() // if `isValid` returns true, form will close, if it returns false, form will remain open
};

[AllanOricil]

I liked the onclose. It wont cause any issues with the current ux and it is up to node authors to adopt.

[AllanOricil]

I would use it like this

// EDITED

definition.oneditclose = function(reason) {
    if (reason === 'done') {
        return isValid()
    }
    return true
};

@Steve-Mcl the name of the new hook would have to be "oneditclose" to follow the naming conventions

[Steve-Mcl]

Equally valid.

But it is just an opening proposal. Lets see if there are any comments good/bad/for/against

It may be that someone comes along and says:

"we cant do this because of abc"
or
"we shouldnt do this because of xyz"
or
"The function signature should also contain a parameter that is an array of property names and changes so I can evaluate if I 'care'"
or
"the return value should be an extensible object (for future proofing) with at minimum, {"cancel": true, "reason": "Validation failed for field A"} so that core can display a toast with a reason string for why closure was inhibited"
or
etc...

[TotallyInformation]

You may want to take a look at uibuilder's main node. On the file edit tab, it does disable the done button if an unsaved edit is outstanding. The node also turns off most settings until the "url" entry has been actually deployed.

[AllanOricil]

The reason I need this feature is because my node forms are highly complex to use defaults.[prop].validate for validations, and jquery to control form states. I'm building my forms using Vue and the validations are done with Json schema.

[Steve-Mcl]

Thats fine too. Just use a custom validator function on your defaults props.

Node properties : Node-RED

[gregorius]

Honestly this sounds like a good way to brick your node red. Want to copy something from inside node red to another field (e.g. user name & password), start with user name, then want go back and add password. But when you want to copy the password, well the panel just won't disappear because now (after entering the user name) the password field is mandatory. So the form is in error.

Well what now? Delete the username or enter a fake password to get rid of the panel.

Definitely not a fan of the proposal. Just a nightmare waiting to jump out of the corner and bite the user ....

[AllanOricil]

@gregorius

Honestly this sounds like a good way to brick your node red. Want to copy something from inside node red to another field (e.g. user name & password), start with user name, then want go back and add password. But when you want to copy the password, well the panel just won't disappear because now (after entering the user name) the password field is mandatory. So the form is in error.

Well what now? Delete the username or enter a fake password to get rid of the panel.

If you want to copy something from within node-red while your form is open, you can just open node-red in another tab and copy the things you need.

[AllanOricil]

I found a solution that won't let the node form dialog close if there are errors.

disableCommitChanges() {
          if (Object.keys(this.errors).length) {
            $("#node-dialog-ok").prop("disabled", true).addClass("disabled");
            $("#red-ui-workspace").css("pointer-events", "none");
          } else {
            $("#node-dialog-ok")
              .prop("disabled", false)
              .removeClass("disabled");
            $("#red-ui-workspace").css("pointer-events", "");
          }
},

EDIT:
It is working as I expected! This shortcut isn't working when there are errors

[gregorius]

@AllanOricil

If you want to copy something from within node-red while your form is open, you can just open node-red in another tab and copy the things you need.

Very convenient. But hey it was the user that made the mistake of entering the wrong data in the first place, let them suffer the inconvenience.

I also don't like this idea because there is no point to it.

If there an error in the form, then as @Steve-Mcl pointed out, there is a visual cue on the flow. And that's about all that changed. No flow was deployed, no change made to the server, nothing breaks. The flow was not changed on the server.

Until the deploy button is pressed nothing bad will happen. And if the user does press the deploy button, they get a warning and need to confirm that deploy. So to all those levels of "danger, will robertson, danger", the idea here to so add another layer of confusion. "Hey where's the done button gone to ... ah ok, there's an error on the form". A definite dark pattern in UI design.

For seasoned users this is a major inconvenience, for new users simply more confusion.

And for what? For pedantically telling the user they are stupid and are now being punished for entering the wrong data.

[AllanOricil]

@gregorius

Very convenient. But hey it was the user that made the mistake of entering the wrong data in the first place, let them suffer the inconvenience.

How can the User to enter the wrong data if validations will still run as usual? Can you explain how this will happen with reproduction steps list? I'm not seeing it because the only change in the current behavior is that the node author can choose if he will or not allow the node form to close if there are errors.

If you install a node that has the new hook, and you don't like the behavior, you can fork the node's source code, if available, and remove the hook from its code.

[gregorius]

@AllanOricil

How can the User to enter the wrong data if validations will still run as usual?

Ok the user enters data in some field with validation and the validations says the data is wrong. The warning lights gone on and the button is gone/deactivated. How does the user close panel?

What I am I missing here?

Of course the validations are running. How can I as a user close the panel to find the right data? I can't. I'm stuck. So I delete the data again. But the field isn't allowed to be empty (hypothetically speaking). What now?

A field is not allowed to be empty, but I as user have no idea what goes into the field. I just opened a edit panel for a node. And immediately it's in error because some field can't be empty. Check the complete node for an example. It's in error when I pull it into the flow. Now I open the edit panel and have no idea what the complete node actually does. Now I can't close the panel because I want to read the help documentation on the complete node. No go. Too bad user, you screwed up, you should have read the documentation before opening the edit panel. Curiosity and cats, a dangerous mix.

(Btw the complete node is the third from the top in a default installation of NodeRED - there is a likelihood that a new user encounters the red-triangle of error before anything else because of the complete node is third from top.)

Now instead I could create an endless loop either using the status node or the complete node and nothing, absolutely nothing prevents me from doing that. All done buttons are there, no deploy warnings but my node red server melts.

Well that's nice. At least the done button is still there so that I can fix the problem ... hm what problem? Nothing in NodeRED is actually telling me what the problem is.

A far more interesting problem to solve is graph theory and to find potential endless loops within Node-RED flows. Now that would be something for which I would deactivate the deploy button! Hey User, you've just created a potential end less loop that might create molten metal of your NodeRED server, do you really want to deploy? If you do decide to deploy, here are the instructions of how to enter safe mode .....

But we'll deactivate the done button instead because a name field can't be empty (hypothetically speaking).

[smcgann99]

I think I'm inclined to agree with @gregorius, this could lead to a very frustrating user experience. There are already several mechanisms in place to warn of the incorrect configuration.

If the user insists on deploying, then the node should should just fail graciously, with a helpful warning.