Address Gemini feedback about handling falsy values - #6077

If prevAnswer or field.default is null (which can happen for optional fields), passing it directly to value will violate the InputBoxOptions type definition (which expects string | undefined) and may cause runtime issues or display "null" in the input box.

We should safely handle null values by converting them to undefined so that the input box remains empty.

@h9jiang hmm, now I'm wondering about this more... If we return null here, should it be added to formAnswers or skipped?

If we say null is used as a signal here to mean "no answer" and then we skip adding it to formAnswers, should the same apply to string fields submitted as an empty string? It might be odd to include those in formAnswers if not doing the same for numbers.

Hi Danny, how about a button on the right top corner like this: (note the -> on the right top corner)

We could use this button to say, user can skip this question and we only render this button when the question is "optional". And if the user hit enter (even it is empty, since empty string is still a valid string), we interpret user intention as an answer so we run our client side validation. (like if this is really a number...) If user hit the skip button then, we consider this as a skip operation and the client will not send this answer to the client.

The following code is generated by Gemini and it seems to meet the requirement. However, we can only render this button for "inputBox" and "quickPick" (which covers every kinds of question except for "file"). IMO, the "ideal" file picker is the native built Quick Open using hot key cmd + p that allows user to fuzzy matching files they are looking for, and this would have support for rendering a "skip" button.

			case 'string':
				return new Promise<string | null | undefined>((resolve) => {
					const inputBox = vscode.window.createInputBox();
					inputBox.prompt = field.description;
					inputBox.placeholder = field.description;
					inputBox.value = prevAnswer !== undefined ? prevAnswer : field.default || '';
					inputBox.ignoreFocusOut = true;
					// 1. Create a custom "Next / Skip" button if the field is not required
					const skipButton: vscode.QuickInputButton = {
						iconPath: new vscode.ThemeIcon('arrow-right'),
						tooltip: 'Skip / Next'
					};
					if (!field.required) {
						inputBox.buttons = [skipButton];
					}
					// 2. Handle button clicks
					inputBox.onDidTriggerButton((button) => {
						if (button === skipButton) {
							// Return null to signify "skipped / not answered"
							resolve(null);
							inputBox.hide();
						}
					});
					// Handle standard submission (Enter key)
					inputBox.onDidAccept(() => {
						resolve(inputBox.value);
						inputBox.hide();
					});
					// Handle cancellation (Escape key)
					inputBox.onDidHide(() => {
						resolve(undefined); // undefined signifies user cancelled the entire flow
						inputBox.dispose();
					});
					inputBox.show();
				});

We will have to make a little bit more change to render the skip button conditionally based on the "required" field but shouldn't be complicated. What do you think?

(edit: this comment was posted before the one above was submitted, so it's out of order and I hadn't read it at the time!)

@h9jiang not urgent, just in case you missed it.. this is a question about how to represent skipped optional answers - if you press <enter> on a string input we might get empty string, not null, but on numbers we would presumably want to use null, which feels inconsistent. I think we should specify something so servers/clients agree.

Hi, what I meant was, as long as user hit <enter> we will consider it as an input even it is empty.

In this case, if the user hit <enter> on a string input, we will consider it as an empty string answer. If the user hit <enter> on a number input, we will consider invalid.

If the user want to skip the question, either for string or number, user should click the -> arrow button. The arrow button is only available for optional questions. What do you think?

I like the idea, but I do wonder if the -> icon is too subtle. Is there any real benefit to distinguishing between empty and skipped? (in a "full dialog" client, I don't imagine this distinction would be made). I also don't imagine that a "required string" field would expect to accept an empty string as a valid supplied value.

So what about just treating any empty inputs as unanswered/skipped? If they are required, they will be rejected during validation and the user forced to provide a value (ofc, if there was a default already entered, pressing <enter> would just have submitted that as the actual value).

(cc @bwilkerson)

Hi @DanTup

I do wonder if the -> icon is too subtle.

I think you are correct, this is probably too subtle. I don't have a strong opinion on this, I think what you have described is also very reasonable.

The way I approached this problem is trying to eliminate ambiguity. I don't like "ambiguous" UI or special/default interpretation. But as you mentioned, the UI for -> is just too subtle.

So I would say, comparing between both solutions, the proposal you got is more user friendly. Let's go with that!