Add abitlity to turn off "On Change" messages for Number Input

[bveenema]

Description

Adds checkbox to "Send message on" section for "On Change". When disabled, node will only send messages on Focus Leave or Press Enter (if checked). Default value for On Change is set to true for backwards compatibility.

Also adds "event" field to the msg output with possible values of "onChange", "focusLeave" or "pressEnter" to enable downstream filtering

Related Issue(s)

Not related to a particular issue # that I found. This problem came up while building a configuration manager using the number input node. Configuration was being updated as I typed number into the field due to messages being sent and no way to determine the source of the message (onChange, focusLeave or pressEnter). For configuration management, we need to be explicit about what values are being set. This solution is better than a "save" button solution which could have triggered all updates.

Checklist

• I have read the contribution guidelines
• Suitable unit/system level tests have been added and they pass
• Documentation has been updated
  • Upgrade instructions
  • Configuration details
  • Concepts
• Changes flowforge.yml?
  • Issue/PR raised on FlowFuse/helm to update ConfigMap Template
  • Issue/PR raised on FlowFuse/CloudProject to update values for Staging/Production
• Link to Changelog Entry PR, or note why one is not needed.

Labels

• Includes a DB migration? -> add the area:migration label

[knolleary]

Thanks @bveenema - well get this reviewed soon. One thought for us to check on is whether we should add a similar option to any other text-based inputs and not just the number input. We should make sure we have a consistent UX between them.

[bveenema]

@knolleary Thanks, I'll look into the tests that are failing. Likely won't be until the weekend.
I did notice that some Dashboard 2 nodes send an "_event" field the msg. I don't recall which ones at this moment but that may be a better semantic place than creating a new "event" field in the root.

[colinl]

It does seem illogical not to add this feature to the Text Input node at the same time, though I note that they are already inconsistent in that the Text node has a send after delay setting.

There are not any help text or docs updates with the PR, but that is perhaps not surprising as the existing help text does not mention any of the static fields. There is a page in the docs, though it is not linked to from the top level widgets page. The text on the node's page does not include any of the Send options. It would probably be worth adding those and the new one. Most of the description can be found on the Text Input node docs.

I agree that the event should be in msg._event as the button widget uses this to indicate the type or interaction. On the button it is an object with additional information, it would be worth considering whether there is any other information that should be included with this event.

[colinl]

If I have an existing number input node and upgrade node red to this branch, restart node-red and refresh the editor, then open the node the new option appears and is checked. Unfortunately when I change the value in the dashboard it does not send immediately. I have to hit enter or move the focus.

If I add a new number input it functions correctly.

[Steve-Mcl]

@bveenema I intend on doing a release in the next few days. Would you be in a position to consider the edge case @colinl has uncovered in his review:

If I have an existing number input node and upgrade node red to this branch, restart node-red and refresh the editor, then open the node the new option appears and is checked. Unfortunately when I change the value in the dashboard it does not send immediately. I have to hit enter or move the focus.

If I add a new number input it functions correctly.

it would be nice to get this one over the line.

Many thanks, Steve.

[colinl]

Also, should it be msg._client, and should it be an object, for consistency.

[BenVeenema-NHI]

@bveenema I intend on doing a release in the next few days. Would you be in a position to consider the edge case @colinl has uncovered in his review:

If I have an existing number input node and upgrade node red to this branch, restart node-red and refresh the editor, then open the node the new option appears and is checked. Unfortunately when I change the value in the dashboard it does not send immediately. I have to hit enter or move the focus.
If I add a new number input it functions correctly.

it would be nice to get this one over the line.

Many thanks, Steve.

I need to dig in more to the issue @colinl is describing. I haven't had any time in the last few weeks to work on this and that likely isn't changing through the end of the year.

I'm happy if anyone else wants to pick it up and work on it in the mean time.

[colinl]

I will take a look at the code.

[colinl]

I have a fix for the issue of existing widgets not sending on change, but I don't know how to make that suggestion in a way that it can be easily incorporated. I see how to suggest changes to lines that are in the commit, but not additional changes. In ui/src/widgets/ui-number-input/UINumberInput.vue, mounted() at line 165 needs this change

 mounted () { // on resize handler for window resizing window.addEventListener('resize', this.onResize) this.onResize() + // allow for the fact that, on upgrade, some properties may be missing, and default as required + this.props.sendOnChange = this.props.sendOnChange ?? true }, 

For the other issues @Steve-Mcl I think you should maybe go ahead with the release without this one. There are some things I want to look into further before saying I am happy.

[colinl]

@bveenema is there a reason that you did not use the same method for sending the event back to the server, and adding msg.event, that the ui-button widget does?

[bveenema]

@bveenema is there a reason that you did not use the same method for sending the event back to the server, and adding msg.event, that the ui-button widget does?

No. I didn't see that there was an existing method until later.

[colinl]

Maybe that should be considered, it might be better if both used the same technique for consistency. I haven't looked in detail so I don't know what the relative merits are.

[bveenema]

@colinl I agree. I assume the existing method uses the "_event" object referenced here: #1922 (comment) ?

[colinl]

Yes, there are two questions

1. Should the event be consistent with that of the button? I would vote for yes, so use msg._event, which contains an object containing the event. That also leaves open the possibility of adding further data to the object if required.
2. The technique used in the code appears at first glance to be simpler in the button node, so it would be worth considering whether that technique should be used.