Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

st.multiselect autocomplete/match not working for numerical values #3108

Closed
ginmob opened this issue Apr 9, 2021 · 6 comments · Fixed by #3294
Closed

st.multiselect autocomplete/match not working for numerical values #3108

ginmob opened this issue Apr 9, 2021 · 6 comments · Fixed by #3294
Assignees
Labels
type:bug Something isn't working

Comments

@ginmob
Copy link

ginmob commented Apr 9, 2021

Summary

st.multiselect autocomplete function does not work for numerical values

Steps to reproduce

Code snippet:

col1 = st.beta_columns(1)
fruit_type = ["apple-4", "apple-17", "apple-78", "orange-175", "orange-176"]

with col1:
    selected_fruit_type = st.multiselect("Select Fruit Selection", options=fruit_type)

(Please provide a code snippet! This will help expedite us finding and solving the problem.)

If applicable, please provide the steps we should take to reproduce the bug:

  1. Click on the multiselect box
  2. Enter 2 and you will get apple-78 as a match
  3. Enter 3 and you will get apple-175 as a match
  4. Enter 0 gets you apple-4 as a match

Expected behavior:

Enter 2, 3 or 0 should not get a match in the dropdown list.

Actual behavior:

See attached screenshots.

Is this a regression?

Not sure. This is my first time using this feature.

Debug info

  • Streamlit version: 0.74.0
  • Python version: Python 2.7.17
  • OS version:
  • Browser version: Version 89.0.4389.72 (Official Build) (x86_64)

Additional information

If needed, add any other context about the problem here. For example, did this bug come from https://discuss.streamlit.io or another site? Link the original source here!
Screen Shot 2021-04-09 at 4 54 57 PM
Screen Shot 2021-04-09 at 4 55 04 PM
Screen Shot 2021-04-09 at 4 55 12 PM

@ginmob ginmob added type:bug Something isn't working status:needs-triage Has not been triaged by the Streamlit team labels Apr 9, 2021
@kmcgrady
Copy link
Collaborator

Thanks for the report! Seems like we should apply #2933 to multiselects as well!

@kmcgrady kmcgrady removed the status:needs-triage Has not been triaged by the Streamlit team label Apr 28, 2021
@ginmob
Copy link
Author

ginmob commented Apr 28, 2021

@kmcgrady That is great to hear! When can we expect the solution to be merged in?

@kmcgrady
Copy link
Collaborator

Hey @ginmob I can't guarantee when a solution will be merged in, but I put it in our bugs project to get addressed. Is there a use case that this bug aggravates? I see why it's a bug, but perhaps not as annoying of one.

@ginmob
Copy link
Author

ginmob commented Apr 29, 2021

Hi @kmcgrady, we use multiselects heavily (because it's awesome!) in all our dashboards and every multiselect dropdown list is long. Using autocomplete feature helps us quickly get to the topics of interests to help filtering and that's how I noticed the bug. We would like people to keep coming back to our dashboards so this search needs to be functional so users can quickly select multiple choices. Currently it's a lot of click then scrolling then click to scroll some more for multiple choices. I hope I am advocating correctly for my case and many others out there! :)

@kmcgrady
Copy link
Collaborator

Thanks for the use case @ginmob ! We will look into it and hopefully get a solution soon. I still cannot make guarantees on a release date, but noted the use case to prioritize this issue.

@trajamsmith trajamsmith self-assigned this May 17, 2021
@trajamsmith
Copy link
Contributor

So — documenting here for future reference — this is due to the way one of the components works in a UI dependency.

The screenshot below is from their docs. You can see that the Select component watches not only for the labels but also for the values, which for us are arbitrarily numbered (and shouldn't be exposed to the user at all). For instance, with an input of 2 the typeahead suggestion is apple-78 because our code procedurally gave it the value 2.

Interesting bug, working on a fix 👍

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants