Proposed flow: Idea 1

1. Insert button is disabled when the input fields are empty
2. Insert button is enabled when input has been typed
3. When editor clicks on insert, validation is performed
   • if there are errors, the Insert button is disabled and the error messages are displayed inline
     • The Insert button is enabled again if changes are made to the input
   • If there are no validation errors, the output is inserted

@gengh Can we retain the current validation onblur alongside this. So if validation has already happened (e.g the user clicks outside or uses the preview) clicking on Insert just inserts the output?
Currently, clicking on insert immediately closes the dialog but with validation happening first in this proposal and taking some seconds we would need to communicate progress. The progress indicator in the input fields wouldn't be so noticeable since the user at that point is focused on the Insert button. What progress indicators are available for the OOUI dialog?

@gengh Can we retain the current validation onblur alongside this. So if validation has already happened (e.g the user clicks outside or uses the preview) clicking on Insert just inserts the output?

Yes, I don't think that would be a problem 👍
It all sounds good, thank you!

Currently, clicking on insert immediately closes the dialog but with validation happening first in this proposal and taking some seconds we would need to communicate progress. The progress indicator in the input fields wouldn't be so noticeable since the user at that point is focused on the Insert button. What progress indicators are available for the OOUI dialog?

@gengh

Proposed flow:

1. Insert button is disabled when the input fields are empty
2. Insert button is enabled when input has been typed
3. When editor clicks on insert, validation is performed
   • if there are errors, the Insert button is disabled and the error messages are displayed inline
     • The Insert button is enabled again if changes are made to the input
   • If there are no validation errors, the output is inserted
   • The current validation on-blur is retained.
   • A progress indicator will show in the dialog header during validation triggered by the Insert button

I have doubts about the proposed solution:

1. Insert button is disabled when the input fields are empty: we cant do this because we now introduced default values, there is a default value set and therefor both age fields are valid.
2. The insert button cant trigger validation. It is outside of our app scope and part of visual editor itself. EDIT: maybe we can do it but it still feels strange to have validation in 2 places. We would need to hook into the store and move all validation there which all feels like a big change while maybe we can solve it in an less complex way.
3. My proposal would be to start validation perhaps already on inputting/typing but with a debounce?

Change #1184149 had a related patch set uploaded (by Genoveva Galarza; author: Genoveva Galarza):

[mediawiki/extensions/WikiLambda@master] Validate fields on model updates, debounce parser validation

https://gerrit.wikimedia.org/r/1184149

This use case is no longer applicable to the Age function, as the default value will make the button enabled from the start even with empty values, but:

• as an editor, I edit a function call to Age which was added previously.
• I clear or change one of the fields: the button should become enabled then.

Also this issue can be replicated on other functions that use inputs with parsers but have no default values:

• e.g. any function that takes Natural Numbers as input (like multiply two natural numbers/Z13539) will have the same issue.

The insert button cant trigger validation.

It definitely can, and it's not a very big deal. However, I don't think it's good usability.
There are also similar issues on string input field, which are totally unnecessary (as this lacks validation). The best option is to stop relying on change events and just use input updates. I'm worried about triggering the call too quick and being a burden to the orchestrator, so setting debounce delay to 1000ms.

@gengh Why do you think it may not be good trigger validation by the insert button(in addition to onblur)?
Do you think debounce (1000ms) will have less premature-validation?

There are different events that trigger validation and different events that handle button disable/enable. By adding a different validation triggering events, we can have different validation processes running in parallel which can become confusing, generate blips (disabled-enabled-disabled) and ultimately generate parallel duplicate calls to the orchestrator. Having only one-way validation is the best option to avoid this.

Do you think debounce (1000ms) will have less premature-validation?

There might be premature validations, for sure, but the field indicates after the debounce time that something is happening (validation) with the loading icon. I think 1000ms is tolerable.

Change #1184149 merged by jenkins-bot:

[mediawiki/extensions/WikiLambda@master] Validate fields on model updates, debounce parser validation

https://gerrit.wikimedia.org/r/1184149

gengh opened https://gitlab.wikimedia.org/repos/abstract-wiki/wikifunctions/function-orchestrator/-/merge_requests/454

Provide error and errortype builtin functions

jforrester merged https://gitlab.wikimedia.org/repos/abstract-wiki/wikifunctions/function-orchestrator/-/merge_requests/454

Provide error and errortype builtin functions

Change #1191171 had a related patch set uploaded (by Jforrester; author: Jforrester):

[operations/deployment-charts@master] wikifunctions: Upgrade orchestrator from 2025-09-16-134119 to 2025-09-24-180530

https://gerrit.wikimedia.org/r/1191171

Change #1191171 merged by jenkins-bot:

[operations/deployment-charts@master] wikifunctions: Upgrade orchestrator from 2025-09-16-134119 to 2025-09-24-180530

https://gerrit.wikimedia.org/r/1191171