The “on enter key pressed” is a good start, but not being able to e.g. react natively if a user changes something on an input creates a lot of issues… i.e. how to determine if some input has to be considered “dirty” since it is changed and a defendant field e.g. needs to run a calculation…
Going via the custom widget “workaround” quickly becomes problematic if there are multiple fields with dependencies…
If either “Zielmenge” or “# je Einheit” inputs change, their result field which is running a calculation should automatically update as well…
I can trigger the calculation manually via pressing the button on the right… but if the user changes any one field, there is no way to capture this and enforce the calculation update prior to any user confirmation or passing to the next step.
This was a pretty intentional limitation that we put in place for one primary reason: performance. Making these inputs capable of running logic on change gives users enough shoelace to trip themselves when it comes to trigger execution time, and the cascading actions triggers can create.
Imagine for a second, that my input field is being used to filter orders that are being pulled from your ERP or MES. Each time a user changes a key, a request needs to be made to an API to return the updated filtered list. Right now the way triggers work, logic will always wait for the connector to return data before proceeding (same with stuff like waiting for a connector to return data). These operations can be slow (when looking at a lot of data, or connecting to a slow system, like an erp over a REST call)
One solution to this would be to significantly limit the types of trigger actions that can happen on change, but this would drive a confusing user experience, given that many of our users lack the context around the cost of different operations.
Another option would be to enable trigger actions that can run asynchronously, which would improve trigger performance but would create a new level of complexity that customers need to understand to be successful.
A third option would be to allow something like regex matching on inputs that run on change, but not full triggers. this would address the needs of many on change type needs, without some of the spike pits that come with full triggers on input.
This gap is something we are thinking about super tactically but is a challenging one to solve. Huge thank you for bringing this cap back to the forefront.
you could recognize the change with a custom widget and triger any calculation with this.
In my opinion the charme with this is, that you only use the change detector, if you thought about this and the chance that you know what you are doing is higher. However I would also like to have a better (implemented) solution.
@Pete_Hartnett for Text and Number inputs it would be possible to trigger, when changing the fokus away from the input field.
@Pete_Hartnett : Thank you for the elaborate answer on the thought process behind this.
While I see that this is certainly not necessarily easy to get right, I would suggest to consider this function at least as an on-demand option for advance folks that know what they are doing.
The example you gave can be easily mitigated if a “denounce” limiter is put in place under the hood. This way multiple events are captured (e.g. keystrokes) and only when a certain time has passed without any interaction the final event is triggered.
It should be non-blocking and the fact that the trigger is still evaluated should be visually apparent e.g. by a sinner on the side of the input widget… like so:
Finally, you could put emphasis on the potential “disruptive” nature of this trigger type by adding a visual note into the trigger editor at the top to remind the user what he is doing.
Yes, you can build a custom widget… but in the use-case stated it will always require a purpose built one as there are n inputs that need to be monitored for any changes in parallel.
We built one that has two text variables and two bool variables to monitor.
You could also add number inputs and you could also scale it to three or four inputs each.
You can then use one or all of the inputs of the widget.
The Event output is something like
Event fired: ChangeDetected "Text 2 from "a" to "abc"
You can add this single widget several times on your step and apply different variables to monitor.
So there is no need to built more than one change detector to achieve this.
Anyhow, it would be very very nice if one could do this without custom widgets as these widgets need to be maintained and significantly (so it seems) increase resource usage during app execution.
@ChrisF and all, thanks for the great feedback! In the long term we certainly want to provide more options for validating inputs. I think On Enter/Exit could be a good short term improvement, we will consider it!
