Skip to content

optimize dropdown search#3768

Open
AnnMarieW wants to merge 4 commits into
plotly:devfrom
AnnMarieW:improve-dropdown-performance
Open

optimize dropdown search#3768
AnnMarieW wants to merge 4 commits into
plotly:devfrom
AnnMarieW:improve-dropdown-performance

Conversation

@AnnMarieW
Copy link
Copy Markdown
Collaborator

Closes #3616

This PR changes the dropdownSearch.ts so it builds the search index once during option sanitization and reuses it instead of rebuilding the index on every search input update.

I tested the example included in issue 3616 with 80,000 options and search performance is now comparable to Dash 3.4.

@camdecoster camdecoster self-assigned this May 20, 2026
Copy link
Copy Markdown
Contributor

@camdecoster camdecoster left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems fine, but you'll need to update references from search_order to searchOrder.

search.tokenizer = TOKENIZER;

indexes.forEach(index => {
search.addIndex(index);
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it matter if the index include here is the same as the uidFieldName passed into the constructor? I ask because indexes always contains 'value' and that's the same as the uidFieldName used in the constructor.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

'value' in the constructor is only used as the document uid field in js-search. It is not automatically indexed for searching, so we still need search.addIndex('value') here.
This is unchanged from previous version (old line 75-77)

options: SanitizedOptions,
searchValue?: string,
search_order?: 'index' | 'original'
searchOrder?: string
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why remove the union type here? In fact, you could reference the existing type in components/dash-core-components/src/types.ts.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good call! It's better to use the correct prop types.

options: SanitizedOptions,
searchValue?: string,
search_order?: 'index' | 'original'
searchOrder?: string
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you'll need to update references to this property throughout the repo.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure what you mean here. But if the type is defined like this, does it have to change anywhere else?

searchOrder?: DropdownProps['search_order']

}
// Preserve original option order
if (searchOrder === 'original') {
const resultSet = new Set(results.map(option => option.value));
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you use map here? Does it allow for faster lookups when only using value?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The map just makes it more robust. It converts the results into a Set of option values instead of object references.

@camdecoster camdecoster assigned AnnMarieW and unassigned camdecoster May 20, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BUG] dcc.Dropdown in dash 4.0.0 is considerably slower than before

2 participants