InteractionService should expose `InteractionInput`-based APIs for requesting confirmation

[captainsafia]

The InteractionService currently models requests for confirmation as MessageBoxInteractions.

aspire/src/Aspire.Hosting/ApplicationModel/InteractionService.cs

Lines 36 to 44 in 6ab1e17

	public async Task<InteractionResult<bool>> PromptConfirmationAsync(string title, string message, MessageBoxInteractionOptions? options = null, CancellationToken cancellationToken = default)
	{
	options ??= MessageBoxInteractionOptions.CreateDefault();
	options.Intent = MessageIntent.Confirmation;
	options.ShowDismiss ??= false;
	options.ShowSecondaryButton ??= true;
	return await PromptMessageBoxCoreAsync(title, message, options, cancellationToken).ConfigureAwait(false);
	}

We should consider modeling confirmation as an InputInteraction and add confirmation to the InputType enum to make the implementation play more nicely with CLI-based UIs where both confirmations and text-based inputs flow through the same pipeline.

Related to this, we should consider renaming certain APIs (like InputsDialogInteractionOptions) to remove assumptions about the type of UI that is used to present an interaction.

cc: @JamesNK @mitchdenny

[JamesNK]

The CLI backend channel would just subscribe to the watch method on InteractionService. It can then send the data to the CLI however it wants.

In the dashboard a confirmation, and an input of type checkbox are very different.

Also, multiple inputs can be sent at once. It wouldn't make sense to have multiple confirmations in a dialog.

[JamesNK]

Related to this, we should consider renaming certain APIs (like InputsDialogInteractionOptions) to remove assumptions about the type of UI that is used to present an interaction.

What should be renamed? Change Select to Choice? Or Checkbox to Boolean?

[captainsafia]

The CLI backend channel would just subscribe to the watch method on InteractionService. It can then send the data to the CLI however it wants.

Yep, we can adapt the MessageBoxConfirmation in the CLI layer to the a confirmation prompt. However, it felt like a bit of a code smell to me to have two different conceptual types for the same semantic concept (Yes/No). Unifying it under the InputType umbrella would also make the make projection that we have to do in the CLI a bit easier. We can always assume that the Interaction is an InputInteraction and rely on the types to disambiguate between the types of prompts.

In the dashboard a confirmation, and an input of type checkbox are very different.

Yep, I think this gets at my concern around the InteractionService being overfit for the way the dashboard models UI. A confirmation and a checkbox are visually different things in the dashboard but semantically I think they represent the same type of interaction: an input interaction that returns a boolean.

Also, multiple inputs can be sent at once. It wouldn't make sense to have multiple confirmations in a dialog.

Yep, agree this makes sense for the dashboard. The CLI has the opposite pattern though: you can only ever prompt for a single input at a time.

I haven't dived too much into the Dashboard implementation but I assume that if you modeled confirmation as an InputInteraction you can always constrain that only a single InputInteraction is sent when you prompt for confirmation?

What should be renamed? Change Select to Choice? Or Checkbox to Boolean?

Yep, strawman for how the InputType enum can be renamed to be less tied to the values that you can provide as a <input type>:

public enum InputType
{
    String,
    SecretString,
    Choice,
    Boolean,
    Number
}

In this case, we might have to model whether an InputType.Boolean is a Checkbox or a Confirm separately in the implementation, hopefully somewhere that is Dashboard specific. The existing MessageIntent might help here?

[davidfowl]

@JamesNK take a look at the cli implementation