Codecov Report

Attention: Patch coverage is 91.30435% with 2 lines in your changes missing coverage. Please review.

Project coverage is 91.56%. Comparing base (85cad19) to head (aacb655).
Report is 3 commits behind head on dev.

@@            Coverage Diff             @@
##              dev   #10433      +/-   ##
==========================================
- Coverage   91.57%   91.56%   -0.01%     
==========================================
  Files         426      426              
  Lines       13311    13334      +23     
  Branches     2567     2571       +4     
==========================================
+ Hits        12189    12209      +20     
- Misses        548      549       +1     
- Partials      574      576       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

I noticed if you get a letter wrong (in this case "Veru" instead of "Verm") it'll go to the next one:

Yes, once a string search fails, there's a fallback to the character search and the standard cycling through results apply. That's how typing T -> T does Tennessee -> Texas add there are no valid results for TT

@danielchalmers would you like it to instead ignore the newly entered invalid character and search for Ver again (dropping the U)

I think every invalid character after a string of valid characters should be ignored and it shouldn't perform a new search until after the debounce.

• Typing Ala selects Alabama. Typing s for Alas within the debounce selects the better match Alaska
• Typing Alab selects Alabama. Typing s is ignored. Anything after this within the debounce is also ignored
• Typing Ala selects Alabama. Typing Ala again AFTER the debounce selects the next match Alaska

I believe that's the behavior of the native select HTML component which is what I'm modeling it off.

I can't use keyboard shortcuts (including search) at all anymore on the SelectFocusAndTypeTest

I can't use keyboard shortcuts (including search) at all anymore on the SelectFocusAndTypeTest

Just pulled this down on my work machine.... all originally documented shortcuts and the updates work as expected.

Will want to wait on @mckaragoz

Should we make this change?

Will want to wait on @mckaragoz

Will look at in 2 days :)

Should we make this change?

tbh, I'm not sure we need it ... would there really be a null select item?

Should we make this change?

I also don't think so. default(T) for int would mean 0 and this could be problematic.

@Anu6is yes users use select item that hold null values. They already opened some issues about highlighted items when the value is null.

All the explained features are very smart. But i have 2 arguments:

1. Actually im not in favor of multi-character search in select. It's more likely of autocomplete or combobox feature.

2. Instead of open popover and search directly while press any key, what about never open popover and search and show the result directly on input? We already have space and enter keys to open popover for standard search. This advanced and direct search sounds like they designed for pro users. A pro user prefers not to open popover, when they press "a" it selects Alabama, when they pressed again, it selects Alaska. With this, they will save maximum time and fill a big form quickly. If we don't need enter key to open popover, we also should not have to press enter key to close popover.

• Actually im not in favor of multi-character search in select. It's more likely of autocomplete or combobox feature.

This is a good point. Some might prefer single character search. We might have to make it configurable.

• Instead of open popover and search directly while press any key, what about never open popover and search and show the result directly on input? We already have space and enter keys to open popover for standard search. This advanced and direct search sounds like they designed for pro users. A pro user prefers not to open popover, when they press "a" it selects Alabama, when they pressed again, it selects Alaska. With this, they will save maximum time and fill a big form quickly. If we don't need enter key to open popover, we also should not have to press enter key to close popover.

I checked with Native HTML Select and it seems to behave exactly like you prefer. Another valid point, I guess. But I can also see users wanting to have the behavior @Anu6is implemented in this PR.

So I guess we could add switches for both to MudGlobal.SelectDefaults. Something like bool MultiCharacterSearch { get; set; } and bool OpenDropdownOnSearch { get; set; } or similar, default values for both to be decided.

The question is, can it be switched easily without adding too much complexity?

@mckaragoz @henon
For multi-character search, the default for the debounce can be set to 0 which would essentially limit it to single character searches. If needed the parameter name could be updated or an additional remark can be added in the documentation (@henon)

Opening the select on any key press was to facilitate the search as the list of items is only available once rendered after opening. I can look into rendering the component in code instead of rendering in the UI.
Edit: _shadowLookup solves this

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

Implemented changes suggested by @mckaragoz
@henon - The default is now single character search, setting a QuickSearchInterval will allow multi-character searches (xml documentation has been added)

@mckaragoz @henon For multi-character search, the default for the debounce can be set to 0 which would essentially limit it to single character searches. If needed the parameter name could be updated or an additional remark can be added in the documentation (@henon)

That's cool.

Opening the select on any key press was to facilitate the search as the list of items is only available once rendered after opening. I can look into rendering the component in code instead of rendering in the UI.

No need to dive deep into this. This technical limitation is enough a reason for the current behavior.