Dear maintainers,
I am very interested in this feature, and even created a workaround using existing capabilities (see issue). The present state of the code is "compiling correctly but untested otherwise". Unfortunately, I am not familiar enough with the inner workings of Streamlit to finish this, or even to judge if what I did makes sense. I hope to either get some feedback to direct me to what else needs doing or be the motivation and foundation for a "proper" implementation by someone else.

Please suggest how to add tests for this functionality.

@Dev-iL Thanks a lot for the contribution! Implementation-wise, this already looks promising. However, adding this feature will require some internal discussions and decisions. I will share this with our product team. One potentially disappointing outcome might be that we will close the PR for now.

We actively decided against adding cell selection in the initial version of dataframe selections since the cell selection event is already overloaded with other functionality (e.g., opening cell details, copy/pasting, editing, etc.). We are closely monitoring #6781 to see how interest in this feature evolves.

We actively decided against adding cell selection in the initial version of dataframe selections since the cell selection event is already overloaded with other functionality (e.g., opening cell details, copy/pasting, editing, etc.). We are closely monitoring #6781 to see how interest in this feature evolves.

@lukasmasuch Thank you for your reply. Interestingly, my rather simple use case requires none of that other functionality, whereas cell selection is critical. I even created a workaround using very ugly tornado hacks that achieves roughly the same thing (linked in the issue).

Might I suggest adding a setting somewhere (perhaps to the df component) that allows a user to choose between cell selection and the other interactions you mentioned?

Hey @Dev-iL, sorry for the long delay, we had a few vacations on the team. Lukas is still out of the office, but I'll talk with him about your PR when he's back this week. Unfortunately, as Lukas pointed out, there are a few UX inconsistencies we'd first want to clean up before adding cell selections (also added a longer comment to the issue here), so I think it's quite likely we'll close this PR for now. I know it's a bit frustrating for your current use case but having an amazing user experience is one of our primary goals for Streamlit. I also don't think we'd want to add a (temporary) parameter to switch between the behaviors, since that seems a bit hacky and unfinished.

Hi @jrieke, thank you for your clarifications. I respectfully disagree that knowing where one clicked in a table goes against "an amazing user experience". I'd say that adding advanced functionality (such as putting interactive charts in cells, or viewing cell details) while skipping the basics is what leads to a suboptimal experience. Having said that, I'm sure your company has considerably more experience designing UX than a lone developer, and one would assume that you guys could come up with a better solution than a parameter, if you wanted. Maybe one of those experiment controls?

BTW, why the urgency to close the PR? Can't you simply ignore it until you're ready to include the feature?

Hey @Dev-iL, sorry for the long delay, I was out on vacation.

I respectfully disagree that knowing where one clicked in a table goes against "an amazing user experience"

Totally agree with you that it doesn't have to go against a good UX, and as I pointed out, we'd totally love to have this feature! But as Lukas and I mentioned, it conflicts with some of the current behavior, which is essential for basic functionality like copy-pasting or viewing cell details. (Please also note that these are behaviors that come with the underlying library we're using, not things we added ourselves).

We'll absolutely get to the point where we can figure out all of these things and add cell selections but as you can see on our issues page, we got over 600 feature requests, so we need to prioritize very aggressively. Right now, cell selections are unfortunately not at the top of that priority list.

I can totally leave this PR open, and please be assured that we'll come back to it at some point!

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.

@lukasmasuch @jrieke
Can you please update what's your actual plan regarding this functionality? It's been tagged with needs-product-approval and planning for months - and now pushed to October according to the roadmap.

Codewise, is there anything that needs to be changed in or added to the PR? Otherwise, let's merge and be done with it!

Can you please update what's your actual plan regarding this functionality? It's been tagged with needs-product-approval and planning for months - and now pushed to October according to the roadmap.

@Dev-iL sorry for the delay, we had lots of other things going on. We added cell selections to our plan for Q3 (which runs from Augst to October), will have a look into which behavior we want and if we can use your PR then!