This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Hey, this is awesome, thanks for the PR! I'm fine with adding this, I think the main question is what we call the parameter:

• default as suggested here. That's what we call the parameter for st.multiselect and will also call the parameter for the upcoming st.pills and st.segmented_control, which allow both single and multi select.
• index as in st.selectbox and st.radio.

In principle, index is a bit more consistent since we are in fact returning an index and it aligns better with st.selectbox and st.radio, which are the two widgets closest to this one. Then again, index is a bit of a weird thing and I'm not sure if we would still do it anymore today... So default seems a bit more future-proof. I'll bring this up for a discussion with the team and will let you know how we decide!

@jrieke Another aspect to keep in mind is that options="thumbs" will render (thumbs_up,thumbs_down) with values (1, 0), so the indices (0, 1) are mapped to the values (1, 0). So the question is, would you pass 0 and get 1 or 1 to get value 1 but index 0. I guess the latter, so that st.feedback("thumbs", default=0) returns 1, but wanted to call it out.

I guess the latter, so that st.feedback("thumbs", default=0) returns 1, but wanted to call it out.

I think whatever value we pass should be what's returned; the default value, the value in Session State, and the returned value should all exist in the same universe.

Hey @wjkim00! Sorry for the long wait, coming back to this now. I think your proposed behavior for calling the parameter default and making the accepted value the same as the return value looks fine.

I know it's been a long time but are you still interested in finishing this up? If yes, it would be great if you could resolve the merge conflicts. Currently, there are some dependency conflicts when I try to run this locally, but once they are resolved, I'll try it out and make sure it works as expected. I'll also ping an engineer to do a more proper code review then.

Hey @wjkim00! Sorry for the long wait, coming back to this now. I think your proposed behavior for calling the parameter default and making the accepted value the same as the return value looks fine.

I know it's been a long time but are you still interested in finishing this up? If yes, it would be great if you could resolve the merge conflicts. Currently, there are some dependency conflicts when I try to run this locally, but once they are resolved, I'll try it out and make sure it works as expected. I'll also ping an engineer to do a more proper code review then.

Hi @jrieke , i'll try to solve this myself since i opened the original issue and 99% of the work has been done. Thank you very much @wjkim00 ❤️

@jrieke opened #12578, rebased to the current develop

Going to close this PR as it's superseded by #12578