feat: add async autocomplete

[ascorbic]

A first pass at adding the async/search functionality to the autocomplete prompt.

I've added a new filteredOptions option, that's a function which returns filtered results, which is optionally async. I've then re-implemented the existing funcitonality using this lower-level function.

There is a little bit of trickery to avoid needing to specify whether the function is async and still skip debouncing if it's sync: it just checks if the result is a thenable, then sets that as a property meaning it skips debouncing for the next keypresses.

I've included some (mostly AI-generated) tests and examples, and all existing tests still pass.

[changeset-bot]

🦋 Changeset detected

Latest commit: 6c5294c

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 2 packages

Name	Type
@clack/prompts	Minor
@clack/core	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[ascorbic]

Please bikeshed this name

[ascorbic]

We need to be able to call this manually, as we're not just rendering on keypress

[ascorbic]

We no longer display "(0 matches)" here, which I think is fine as there's "No matches found" imemdiately below. This is because we don't show it unless the user has entered some text. Previously the check for whether to display the number os results was if the total number of items is different from the filtered number, but that's not usable now.

[43081j]

i'd like to avoid needing two option types ideally

in my attempt at this, i ended up with:

interface AutocompleteOptions<T extends OptionLike>
	extends PromptOptions<T['value'] | T['value'][], AutocompletePrompt<T>> {
	options: MaybePromise<T[]> | ((this: AutocompletePrompt<T>) => MaybePromise<T[]>);
	filter?: FilterFunction<T>;
	multiple?: boolean;
}

most of the changes in the constructor then go away, because the constructor just needs to set #options. the overridden prompt is what would initialise the first set of options.

in that, mine does this:

	protected async _initializeOptions(): Promise<void> {
		const optionsResult = this.options;
		const isAsync = isThenable(optionsResult);

		if (isAsync) {
			this.#isLoading = true;
			this.render();
		}

		const options = await optionsResult;

		this.#resolvedOptions = options;

		if (isAsync) {
			this.#isLoading = false;
			this.render();
		}

        // existing untouched logic here from the constructor in main

this same pattern happens in the user input handler, and the prompt renderer itself uses resolvedOptions (a getter that just returns #resolvedOptions) instead of options

let me know what you think. i'd like to get this PR shaped in a way that we both agree rather than me just going off and doing a different thing

[ascorbic]

This looks reasonable. This presumably needs you to pass a () => true filter function, which is quite awkward DX. I wonder if there's a better way to do that.

[43081j]

you're right and i don't like that either 😅

i wonder if we need a filterStrategy: 'local' | 'remote' or some such thing

[ascorbic]

This is the original reason why I had the filtered and unfiltered arrays as separate args