Prompt for values

[JamesNK]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

There are scenarios where values need to be supplied by the user before something can run correctly. To support getting these values at runtime, a service could be added that components or commands could use to ask for a value.

For example, a resource command might use extra arguments. An add-products command could ask how many products should be added, which is sent to the user (either via dashboard UI or command line), the user enters a value, the value is routed back to add-products, and the command completes.

Describe the solution you'd like

An API

public sealed class ValuePromptService
{
    public async Task<ValuePromptResult> PromptValueAsync(PromptedValue value, CancellationToken cancellationToken);
}

public sealed class PromptedValue
{
    public string Name { get; init; }
    public string DisplayText { get; init; }
    public PromptedValueType ValueType { get; init; }
    public List<object> Enum { get; init; }
}

public enum PromptedValueType
{
    String,
    Integer,
    Boolean
}

public sealed class ValuePromptResult
{
    public required bool Success { get; init; }
}

Additional context

No response

[davidfowl]

We need to be able to show to select list as well and get back a list of options. Maybe this should be a form builder 😅

[davidfowl]

cc @mitchdenny

[mitchdenny]

I think you can look at IInteractionService, particularly the Prompt calls:

aspire/src/Aspire.Cli/Interaction/InteractionService.cs

Line 55 in 039c425

public async Task<T> PromptForSelectionAsync<T>(string promptText, IEnumerable<T> choices, Func<T, string> choiceFormatter, CancellationToken cancellationToken = default) where T : notnull

You want to be able to prompt for selection where you get a list of objects (and a function that provides a string representation of that object) and the UX lets you pick one. Then you want prompt for string, prompt for confirmation. That covers most of the scenarios I think.

[mitchdenny]

Heads up @adamint. For the Aspire CLI -> extension integration we are implementing a custom IIntegrationService which is activated when we know that the extension is launching the Aspire CLI. I think one of the end to end scenarios we want to enable here is that if we launch an apphost that wants to prompt for parameters that it can prompt both in the CLI, the extension, and in the dashboard. And I guess its a case of which one resolves first.

[JamesNK]

We need to be able to show to select list as well and get back a list of options. Maybe this should be a form builder 😅

I think we can get progressively more complex as needed. Although we need to keep in mind that what we ask for needs to support a dashboard form or CLI. CLI will limit how complex we can be.

[mitchdenny]

Yeah, ultimately that is why I mentioned the interface we already have in the CLI. It seems to meet most requirements for prompting so far. I think we are going to end up with 3 prompting systems but driven by a core set of annotations in the app model.

[JamesNK]

I think one of the end to end scenarios we want to enable here is that if we launch an apphost that wants to prompt for parameters that it can prompt both in the CLI, the extension, and in the dashboard. And I guess its a case of which one resolves first.

Yeah this is how I imagined it working. The app host can ask for a value, and then that goes out to "value providers" (i.e. CLI or dashboard) and then the user can choose to enter a value using on of the providers. Or there could just be one, such as only the dashboard if the user launched the app from the IDE. When a value is provided then the interaction service tells the other providers to cancel asking for a value.

The value provider could also be hardcoded in the case of running inside a unit test.
Or if you're in a unit test and no value provider is registered then it would error.

[mitchdenny]

Yep. And via the CLI you could get to the extension.

[JamesNK]

How I imagine this working in the dashboard:

1. There is a new log running gRPC streaming call, e.g. InteractionStream. The dashboard calls it at startup and is continuiously listening for new interactions. The dashboard is already doing this to listen for resource changes.
2. The app host can ask for an interaction/value, and provides the info required. The dashboard interaction provider (possibly along with the CLI interaction provider) is registered in the app host. The dashboard interaction provider sends the interaction request over the stream to the dashboard.
3. Dashboard receives the interaction, opens a modal dialog using info required, e.g. modal title, display text, value type requested, choices, yes/no confirmation. The dashboard renders the dialog.
4. If user enters a value then it is sent back on the InteractionStream, the dialog closes, and the value is returned to the component/command that is asking for it.
5. If the user clicks cancel then that notification is sent back.
6. If the user doesn't use the dialog and provides the interaction via the CLI then the app host sends a notification over the stream that the value is no longer needed and the dialog closes.

[davidfowl]

My sniff test for this feature is this experience:

https://learn.microsoft.com/en-us/dotnet/aspire/azure/local-provisioning#tooling-support

This should be trivial to implement with what we design here.

[mitchdenny]

@JamesNK I would tweak that implementation sketch to take into account that you might have validation logic that you want to execute in the apphost that verifies that the value provided is OK. You don't necessarily have to get it working in the first pass but you'll definitely want it eventually because the moment you have user input you have invalid user input.

[JamesNK]

I'm guessing validation would have to ultimately happen in the app host. That means a value would be sent from the dashboard back to the app host, interaction service runs the validation callback, and then either success or validation failures are sent back to the dashboard.

Are you doing validation today with the CLI interaction provider?

[mitchdenny]

It's a function of spectre console but when we do parameter prompting in CLI we'll be dealing with the same design challenge.