Ensure gr.Dropdown can have an empty initial value

[hannahblair]

Description

In PR #7401 we changed the initial value of value from [] to undefined. This means that the else check in the following logic was being run because value is now treated as Falsy:

if (value) {
        old_selected_index = choices.map((c) => c[1]).indexOf(value as string);
        selected_index = old_selected_index;
        if (selected_index === -1) {
	        old_value = value;
	        selected_index = null;
        } else {
	        [input_text, old_value] = choices[selected_index];
	        old_input_text = input_text;
        }
} else if (choices.length > 0) {
        old_selected_index = 0;
        selected_index = 0;
        [input_text, value] = choices[selected_index];
        old_value = value;
        old_input_text = input_text;
}

when the else if (choices.length > 0) expression passes, we set the selected index to 0, and then set value to 0, resulting in the None value behaviour breaking. So this PR changes the default value back to [].

Closes: #7429

🎯 PRs Should Target Issues

Before your create a PR, please check to see if there is an existing issue for this change. If not, please create an issue before you create this PR, unless the fix is very small.

Not adhering to this guideline will result in the PR being closed.

Tests

1. PRs will only be merged if tests pass on CI. To run the tests locally, please set up your Gradio environment locally and run the tests: bash scripts/run_all_tests.sh

2. You may need to run the linters: bash scripts/format_backend.sh and bash scripts/format_frontend.sh

[gradio-pr-bot]

🪼 branch checks and previews

•	Name	Status	URL
	Spaces	ready!	Spaces preview
	Website	building...
	Storybook	ready!	Storybook preview
🦄	Changes	detecting...

---

Install Gradio from this PR

pip install https://gradio-builds.s3.amazonaws.com/346c255c190ca71ef69475cbca948f2fb8340893/gradio-4.19.0-py3-none-any.whl

Install Gradio Python Client from this PR

pip install "gradio-client @ git+https://github.com/gradio-app/gradio@346c255c190ca71ef69475cbca948f2fb8340893#subdirectory=client/python"

[gradio-pr-bot]

🦄 change detected

This Pull Request includes changes to the following packages.

Package	Version
@gradio/dropdown	patch
gradio	patch

• Maintainers can select this checkbox to manually select packages to update.

With the following changelog entry.

Ensure gr.Dropdown can have an empty initial value

Maintainers or the PR author can modify the PR title to modify this entry.

Something isn't right?

• Maintainers can change the version label to modify the version bump.
• If the bot has failed to detect any changes, or if this pull request needs to update multiple packages to different versions or requires a more comprehensive changelog entry, maintainers can update the changelog file directly.

[abidlabs]

Ah interesting. I hadn't realized that the default behavior before 4.19 was to have no option selected in the Dropdown. This is different than how the <select> element works in HTML, where the first element is automatically selected. I slightly prefer the behavior of automatically selecting the first element because that way, the value of the Dropdown is always valid and the user doesn't have to worry about handling the case where the value is None. That being said, since the behavior was previously different, we should not introduce this breaking change.

Change looks good to me @hannahblair, thanks for adding the tests! I also confirmed that #6853 is still fixed with this change.

[abidlabs]

Thanks @hannahblair and @yvrjsharma!

[hannahblair]

Ah interesting. I hadn't realized that the default behavior before 4.19 was to have no option selected in the Dropdown. This is different than how the <select> element works in HTML, where the first element is automatically selected. I slightly prefer the behavior of automatically selecting the first element because that way, the value of the Dropdown is always valid and the user doesn't have to worry about handling the case where the value is None. That being said, since the behavior was previously different, we should not introduce this breaking change.

Change looks good to me @hannahblair, thanks for adding the tests! I also confirmed that #6853 is still fixed with this change.

@abidlabs I agree - I initially didn't see an issue with the new behaviour but figured it could be a breaking/frustrating change 😁