[Coming soon] Ability to accept input from Charts, Tables, etc.

[tvst]

What if every output element could also serve as an input widget?

Then you could do things like:

• User clicks on chart datapoint → python script receives the value for that data point and does something with it
• User zooms into a chart → python script receives the new zoom bounds and does something with it
• User clicks on dataframe rows → python script receives row index and does something with it
• User click on two points on an image → python script draws a rectangle touching those points
• User edits a row on a dataframe → python script receives the new dataframe

Related discussions:

• https://discuss.streamlit.io/t/hover-and-click-events/586
• https://discuss.streamlit.io/t/setting-data-from-javascript/965/2

---

Community voting on feature requests enables the Streamlit team to understand which features are most important to our users.

If you'd like the Streamlit team to prioritize this feature request, please use the 👍 (thumbs up emoji) reaction in response to the initial post.

[MarcSkovMadsen]

Eventually you will be building that kind of functionality (is my guess). Very much needed to provide awesome interactivity. :-)

[markopy]

Other issues that depend on having this kind of functionality: #298 #271

[tvst]

Another one: ability to get the time from an audio widget. See forum thread here.

[treuille]

If you want to select rows in a table, you can use this somewhat inelegant workaround, which will scale up to about 1000 rows or so. 👍

[MarcSkovMadsen]

Here is just my few cents.

If we supported the ipywidgets then we would also get access to the awesome qgrid/ slickgrid.

That grid is really great to read, sort and filter. And it's fast. But I guess the looks of it is not very Streamlit like.

[MarcSkovMadsen]

You can see plotly's new FigureWidget in action here and how it plays well with the ipywidgets and supports call backs.

https://plot.ly/python/figurewidget/
https://plot.ly/python/figurewidget-app/

[rmitsch]

That would be a great feature, since it might allow to support brushing & linking between charts in streamlit apps. For reference, dc.js is a cool JS chart framework that focuses on getting exactly this kind of interaction/dependency between multiple charts right (example). That kind of functionality would be awesome in streamlit.

[torwag]

Esp. Tables as inputs or resp. changeable, like a spreadsheet, would allow using streamlit.io as a replacement for a lot of excel-file based solutions, which are floating around in the millions in cooperate settings.
Streamlit.io would enable a programmer to really get the logic right, access databases, transfer data, have sanity checks, etc. using pandas resp. python in a single file, but still allows everyone to contribute or change data of that "online-spreadsheet"-system.

[treuille]

@torwag : I think this is a super valid use case. Can you please tell me a bit more about the setup you envision. Would you want only a single "spreadsheet" (i.e. table), or would you want graphs etc? Do you want widgets / sidebar? Also, what industry are you working in? Thanks!

[torwag]

@treuille My vision would be to have all possibilities, like graphs, buttons, sliders etc. but also have editable tables, thus people can contribute data to it. Possibilities are endless.
From inventory where people type in the stock amount to annotation of medical data.

I am in an university setting, and here we would have both academic and administrative use for such a solution. E.g. staff and lecture dashboards to show all kind of information on a single page. But enable the user to make inputs where necessary.

[hcoohb]

I would love also to have the output from a selection on a graph.
Plotly allows to select certain points, and I wish I could use this as a input for some other graphs displaying more details...

[tvst]

Just a quick update: we're currently brainstorming a few other features that touch on this one, so it would be great to hear some more use cases from you all, to better inform our discussion.

Even better if you provide a tiny toy example with some arbitrary API! For example:

st.write("Pick a user to edit")

# In this example, st.Table (with capital T) returns an object with properties you can use.
# This is not something that exists today. Just one of the many possible APIs for this...
table = st.Table(users_table)

if table.selected_row is not None:
  user = users_table[table.selected_row]
  show_editor(user)

[MarcSkovMadsen]

But if the functionality at its core could be based on being able to subscribe to any event. That would be very powerfull. The core functionality could then be wrapped into a simpler api for tables, charts etc.

With Dash you can add a callback to any kind of event. In Panel you can do reactive programming in Python using Streams. And here is an example of a Stream from the front end http://holoviews.org/reference/streams/bokeh/RangeXY.html. That concept is really powerfull but maybe too much for Streamlit?

[mstump]

I'm interjecting as a hopeful user of streamlit, we're evaluating a transition from Bokeh which uses slick-grid as it's table implementation. If you do decide to introduce an editable datatable can we add ag-grid to the evaluation list? Slickgrid is not very attractive, has a number of bugs related to sortable grouped columns, and has odd editing behavior where cell state for drop-down columns isn't retained until you switch focus away from the cell. There are some working python bindings for ag-grid which may be a good starting point.

[MarcSkovMadsen]

Here is a an example use case from a user https://discuss.streamlit.io/t/plotly-click-events-in-streamlit/1419

[treuille]

@mstump : Thanks for putting ag-grid on our radar. It looks pretty sweet!

[treuille]

Thanks for providing that context, @MarcSkovMadsen! My current though (happy to be convinced otherwise) is that @tvst's suggestion above would allow us to integrate this kind of table selection (or point selection, respectively) within Streamlit's event model.

The main advantage of this approach is simpler state handling, since the user doesn't need to think about explicitly mutating program state.

The main disadvantage is performance (for now).

Are there are things I'm missing?

[treuille]

Oh, and happy new year! 🎆

[adamkgoldfarb]

Just chiming in that the geospatial use case is pretty apparent: if one could take the st.Table's selections and then set an opacity/color on a scatter mark or polygon with those selections, that would be immediately useful for visualizing subsets of your geospatial data. Here's to hoping that the API feeds nicely into the emerging pydeck integration!

[katsou55]

Hey guys, my 2 cents: another use case you might consider in the industry is data annotation. I have a webapp made of Jupyter + ipywidgets + qgrid + voila that currently allows not only my stakeholders to navigate and explore the data but most importantly, they can annotate data. Also, I have a section to serve "low confident" predictions and downstream improve my models, i.e. active learning.

Therefore, IMHO considering something like qgrid may add plenty of value to Streamlit (ps: that's why I am still using this stack instead of streamlit 😅)

Recap, 2 great use case for qgrid are:

• data annotation
• active learning (for tabular or text data)

Hope it helps, cheers!

[dansbecker]

Another use case for selection in tables:

I'd like to use rows in a table to control what I graph elsewhere in my app (roughly what you'd get if you could embed an st.checkbox in each row of an st.table.)

Forum post about it here

[erwindassen]

Another tool that could make this feature request easier to implement would be to use d-tale: https://pypi.org/project/dtale/ It uses flask as a back-end and already integrates with jupyter so perhaps with some hacking it could take care of all interface elements with the dataframe inside streamlit? Just throwing ideas here.

[SimonBiggs]

An amazing editable react table/spreadsheet widget is the following:

https://blueprintjs.com/docs/#table/features.editing

Also an example of an editable table in a streamlit like project is the following:

https://mybinder.org/v2/gh/SimonBiggs/scriptedforms-examples/master?urlpath=scriptedforms/use/detailed-example.md (scroll down to the "table variables" heading)

Mentioned these in the following issue, but I'm going to close that one, as here is likely the best place for that.

#1345

[rsheftel]

There has been discussion of aggrid here and I use that in Jupyter Notebooks they are beautiful, and allow a wide range of functionality as well as fast.

There is a package of python bindings to wrap it here:

https://dgothrek.gitlab.io/ipyaggrid/

[Laksh1997]

Keen to see this feature manifest

[SimonBiggs]

Bike shedding:

For # 1 what about rerun_on_select=True

[Chiyun-Lee]

Amazing stuff! Really looking forward to the release of the experimental version!

[lukefullard]

So cool, thank you!
Would the proposed API also work with plotly scatterplots on maps?

https://plotly.com/python/scatter-plots-on-maps/

[jrieke]

Would the proposed API also work with plotly scatterplots on maps?

Yup!

CleanShot.2024-04-09.at.21.56.31.mp4

[jrieke]

For # 1 what about rerun_on_select=True

We want to keep it aligned with the on_change parameters we have on input widgets today, that's why we went for on_select. In the future, we want port the on_change parameters to use the same pattern as on_select, so you can both enable/disable change events on input widgets as well as pass a callback.

[benlindsay]

I also would have liked something a little clearer like rerun_on_select=True. If we're constrained to using on_select, then I highly prefer on_select="rerun" over on_select=True. Makes it clearer what to expect.

Thanks for all the work on this! very exciting

[mattbgdata]

dataframe selections

This is amazing and exactly what we need. What are some rough timeframes for this bad boy to be released?

[allocater2]

The proposed solution is very laggy. It takes up to 1 second for the click to be processed.

How many solutions are there by now? Do all streamlit-based solutions have this issue because of the rerun-architecture? If yes, then this is probably the sign that if you want a responsive app you should switch from streamlit+plotly to javascript+plotly.

edit: I deployed the wheel file to the github codespace and running it from the github code space is actually not that laggy. But I have not figured out how to deploy it to the streamlit.app space that is connected to the github codespace. streamlit.app still uses the old/current streamlit and not the new wheel version.

edit2: To clarify, after doing:

pip install streamlit-1.32.2-py2.py3-none-any.whl

There are actually 3 ways to test it in a github codespace:

1. In the simple browser inside the codespace page, next to the code (does not work)
2. In the terminal, starting streamlit run Hello.py (works)
3. In the real webpage on xxx.streamlit.app (does not work)

edit3: Now it also works in the side-browser for some reason. I have streamlit==1.32.2 in the requirements.txt

[jrieke]

This is amazing and exactly what we need. What are some rough timeframes for this bad boy to be released?

Probably mid May, you can follow for updates on #688!

[jrieke]

@allocater2 We have some documentation on how to commit changes from Codespaces and make them show up in your deployed app. In your case, you'd probably want to upload the wheel file to your repo directly and then install that as a local file via requirements.txt.

About reruns: Yes, that's the basic concept of Streamlit, it always reruns your app from top to bottom upon user interactions. In most cases, that shouldn't be too laggy, unless you're e.g. doing expensive computations. If your app feels slow, I'd recommend you to look at fragments (a way to rerun only part of your app) and caching (a way to cache expensive computations).

[Chiyun-Lee]

Mid-May! Perfect timing for our publication - keep it up team! Can't wait 🙏

[allocater2]

Thanks, that worked. I have this in the requirements.txt now:

#streamlit==1.32.2
./streamlit-1.32.2-py2.py3-none-any.whl

We'll see how slow it is with the data I want to use. Thankfully it only has to run locally and not on the web. The web is just for collaboration.

[SimonBiggs]

We'll see how slow it is with the data I want to use.

Hi @allocater2, I can confirm with @jrieke, just because Streamlit "always reruns from the top" that doesn't have to equate to "slow".

The "always rerun from the top" means that the execution model is simple to reason about (which is a huge plus), and with appropriate caching of the key load bearing items many steps do not need to rerun.

In practice I have found that I have never hit an issue where Streamlit rerun speed has became a limiting factor in the applications I have built when using the appropriate caching approaches.

[Glypican]

I tried streamlit-1.32.2-py2.py3-none-any.whl and it doesn't appear to capture click events for plotly heatmaps. I tried both px.imshow and go.Heatmap - I'm guessing this is because click event =/= select event.

[LukasMasuch]

@Glypican yep, the current implementation will only capture select events and no click events :(

[allocater2]

Does the new method work for "select" or "pick" events for a pydeck_chart? Or is there another method for pydeck_chart?

[LukasMasuch]

@allocater2 with the 1.35, we will add selections to plotly, altair, vega_lite_chart, and dataframe. Selections for pydeck_chart will be added in a later release.

[allocater2]

Great. In the meantime I was trying dash+dash-deck and it seems they also never implemented click/selection events. The only map I have gotten to work so far is dash+leaflet with the "n_clicks" event.

[Glypican]

FWIW, I successfully used the streamlit-echarts library to perform onclick callbacks to streamlit from individual heatmap cells. I use the callback to filter a data table, showing the rows corresponding to the heatmap cell. Just mentioning for the next person who comes looking :-)

[LukasMasuch]

We just merged row & column selections for st.dataframe and it will be released in 1.35. You can activate selections via on_select and configure it via selection_mode, e.g.:

selection = st.dataframe(df, on_select="rerun", selection_mode="single-row")

Or for multi-row & column selections:

selection = st.dataframe(df, on_select="rerun", selection_mode=("multi-row", "multi-column"))

You can try it out in this demo.

[jrieke]

@allocater2 I created a feature request for adding selections to pydeck; please feel free to upvote and describe your use case there; that helps us a lot with prioritization! ❤️

[jrieke]

Hey all! We just merged selections for st.plotly_chart, st.altair_chart, and st.vega_lite_chart and they will be released together with dataframe selections in 1.35 next week!!

You can then activate selections via the new on_select parameter, e.g.:

event_dict = st.plotly_chart(chart, on_select="rerun")

Since we now support almost all interactivity features mentioned in the original issue, we decided to (finally!) close it. I created separate issues for a few additional events we want to expose in the future. Please upvote and comment on those, and feel free to open new feature requests for additional events we should support!

• Selection events for maps #8653
• Zoom/pan events for maps #8654
• Zoom/pan events for charts #8655
• Selection and click events for st.image #298

Thanks everyone for your feedback over the years! ❤️