The next frontier for Streamlit: our feature roadmap for 2023 and beyond

My personal Wishlist.

(I am aware that some of my wishes already have been granted by additional modules)

Plotly:

  • get feedback from events, clicks (already on Roadmap: ‘Selections on charts’)

Tabs:

  • Markup in Labels - to also use headings etc. (maybe on Roadmap: ‘Allow markdown in widget labels’)
  • Possibility to switch between tabs programmatically. e.g: When a button in the sidebar gets clicked and the page is rerun the second tab gets selected/shown, maybe by declaring tab2.show() or tab2.active(), tab2.select()

Dataframes:

  • Make Selections possible (already on Roadmap: Selections on dataframes)

Multipage Apps:

  • I do not like the fact that in multipage apps the data from session_state of all apps gets merged together. I would prefer it when I could access it more like st.session_state.page_5.my_selectbox. This looks more structured and “feels safer”. It avoids “naming colissions” when combining apps.
  • The icon/emoji from the “main page” should be default for all “sub pages”, as long as no other icon has been specified
  • Switch between apps programmatically

The bestest of all Ideas for Selectboxes

  • I want to be able to give any list of Objects, like dataclasses, to a selectbox and have nice labels. We could define a special method to return proper labels. Let us call it __label__. I am such a genius (:sweat_smile:Turns out that is how it already works, I just have to specify/overload the __str__ method to creates nice labels. :flushed: Well now I have to simplify some of my code)
6 Likes

If case this is helpful, I managed to do this with CSS in my markdown:

full_width_buttons = """
                <style>
              
                section[data-testid="stSidebar"] div.stButton button {
                width: 100%;
                }
             
                </style>
                """

st.markdown(full_width_buttons, unsafe_allow_html=True)

This was for my sidebar though, not sure how well it’ll play for any container.

Bandcamp Explorer (bc-explorer.app) if you’d like to see it in action :slight_smile:

4 Likes

Starting version 1.18.0, you can pass use_container_width=True to st.button!

4 Likes

Though I’d repost here since I didn’t get a reaction over on the other roadmap thread. Would appreciate somebody from the streamlit team commenting.

Hi, this is a great high-level roadmap and thanks for sharing it publicly.

We’ve been building our commercial app using Streamlit for the past several months. It has been great for productivity. Streamlit excels at making it dead easy to spit out nicely formatted data on the screen. This is huge.

But there are two areas that are pretty major gaps if Streamlit intends to graduate from a prototyping / internal tooling framework to one where commercial applications are developed (is the latter even a goal?)

Control over full page layout - Creating a nice UX around page content is very hard and frustrating (as you know, controlling page layout, sidebar, header bar, navigation etc. has no first-class support). Visual customization ++ and Custom components v2 themes on your roadmap capture this it seems. However, I feel it hasn’t been prioritised enough when looking at the quarter-level plans. Maybe you are working on it right now but only materialising middle of next year, which is fair enough. I can understand this is likely a pretty major change.

Low-level server API - provide access to read/write HTTP headers, lifecycle hooks, middleware. The most significant use case we’ve struggled with is authN/Z. persisting an auth token / JWT across sessions can only be done it seems using cookies rather than a standard authorization header (if we’ve missed a trick please tell us). How can one instrument an app with observability tracing tools? Setting up REST endpoint using frameworks isn’t possible. Looking at the architecture it seems like most if not all of this can be enabled by exposing the web server instance maybe with a few lifecycle hooks.

Overall it would be great if you all took a layered approach and gave access to the lower layers as an escape hatch.

Thanks :pray:

2 Likes

It would be great to have a:

  1. list component, that you can customize.
  2. Layout to elements , or only containers(horizontal | vertical), to help not using to much columns.
3 Likes

Thank you for all the feedback!

@janaka please feel free to also share this feedback in GitHub Issues (which is the primary place our product team takes feedback from) – in particular, these are a few issues you might be interested in:

  1. Widget attribute to hook into for custom CSS
  2. Request: on session start/shutdown hooks
2 Likes

I not see “Custom components v2” in the roadmap anymore.
Not even in “future”.

If i remember correct, was planned for this quarter before.

Has been deprecated?

i hope not, cause currently, is kinda difficult to create one. And the performance is not very good. With components still raising this error

3 Likes

Hey @iuiu,

Thanks for pointing this out! We’ve updated the roadmap app – Components V2 is back in the Future section :partying_face:

1 Like

lovely, thanks.

a couple of questions

  1. why components v2 has been moved from feb-april to future?
    as stated above, performance in components, seems slower than native st. This limits the growth & customization of st
  2. how’s the roadmap’s next quarter planned? follows any voting system in github? or it’s an internal thing?
    from my end, i would like components v2, css integration,and Visual customization. Where could i vote for this?
1 Like

Hey @iuiu,

Components v2 was moved due to engineering capacity and some remaining open design questions.

Our roadmap is determined by a combination of community demand (via voting on GitHub issues) and team capacity.

Here are some relevant issues for the enhancements you mentioned:

For components v2, there are a number of relevant GitHub issues depending on what your primary concern is (i.e. performance vs. visual customizability)

1 Like