I am building a page which let the user to run a query against my database, once I have the data I would like to perform a simple exploratory data analysis of the data.
The problem arise when, at button of the page, I let the user choose any column of the data set with a selectbox to make a countplot. When the user perform that action, every single element of my page is rendered again and it creates a really poor user experience with the page.
When I load the data I use the decorator of cache with the allow_output_mutation option set true
Re-running top-to-bottom is the core of the Streamlit execution model, and where you don’t want to re-run things you can use st.cache (which you’ve indicated you’re using). So it sounds like you are doing what you’re supposed to.
Can you post a code snippet that demonstrates the problem?
with st.beta_expander('Grafical distribution of the columns', expanded=False):
fig_hist, ax = plt.subplots(figsize=(50, 30))
ax.xaxis.set_major_formatter(plt.FuncFormatter(format_func))
ax.yaxis.set_major_formatter(plt.FuncFormatter(format_func))
df.hist(bins=30, color='r', ax=ax, xrot=90)
fig_hist.tight_layout()
st.pyplot(fig_hist, clear_figure=True)
with st.beta_expander('Explore Categorical Columns', expanded=False):
fig_count = plt.figure(figsize=[25, 12])
hue_column = None
column = st.selectbox('Choose Column', ['<select>'] + df.columns.tolist())
if not column == '<select>':
a = sns.countplot(x=column, hue=hue_column, data=df)
a.set_xlabel(f'{column}', fontsize=24)
a.set_ylabel(f'Count', fontsize=24)
st.pyplot(fig_count, clear_figure=True)
In my use case scenario, moreover to show a distribution of the columns dataframe, I want to show a count plot of the categorical columns. So my problem comes when an user choose an specific column, the whole page will rerun, producing a terrible user experience. Most probably I am making a bad use of it
This is currently being designed, and we would be grateful if you could provide us with examples of app/workflow you would like to design without too much challenges!
I’m really glad you are working on that. Streamlit has a bright future.
For example:
I tried to design an app that a part of it requires a password to access. However, with every new user input value, the page is reloaded and the password is asked again.
In the meantime, you could check the st.forms method (blog post) to prevent page reloading on every user input, using instead a submit button to run the script login. Though you would still need to save that you are connected inside the unofficial SessionState.
Cool @andfanilo , I was precisely using st.forms (great feature by the way), but not SessionState. Once it becomes robust and official, it will definitively put Streamlit on another level.
When the user enter name / password and presses submit button
You can run a check to see if they are correct or not.
If the credentials are correct create a session variable .
if you want a logout button. Create a logout button which will delete the session variable.
So in whatever part you want to display only if the user is logged in you can check if the session variable is present or not. if present display that content.
I already had a look at the forms and it’s not what I want, although the feature is great
But yes the streamlit session state is exactly what I need, thanks a lot, it works perfectly and is as easy to use as the other features! Thanks for everything, Streamlit is really amazing
Hi ,
I see it’s a common post in the community forum. So here’s few workarounds I jotted down in this Blog Post or you can find similar content on this detailed video. Hope it helps.
Hi, I have a similar problem. my code looks like this:
import streamlit as st
def heavy_calculations():
# do some slow calculation
data = heavy_calculations()
st.write('## before filters')
st.dataframe(data)
col1, col2= st.columns(2)
upper_filter = col1.number_input("upper threshold")
lower_upper = col2.number_input("lower threshold")
# some filtration and styling
st.write('## after filters')
st.dataframe(data)
I need a solution to not reload the page on each filters choice and instead only apply them. I don’t want to use cahing
Just wanted to give a quick update since this post gets a ton of views. We are not working on a feature to prevent reruns at the moment. It’s something that touches on the fundamentals of Streamlit so we’ll need to think it through carefully. This takes time and we are currently focusing on other features.
Some workarounds (forms, caching, session state) were already posted above. These should solve most use cases!
I opened a feature request on Github for this topic. If you have use cases, please post them there and upvote with . This helps us prioritize and figure out how to best tackle this problem. We try to have all feature requests on Github, so we don’t need to comb through thousands of posts on the forum for planning.
I am working on an application that needs user inputs and based on that inputs creates graphs. But, yes, using a submit button from a form or sliders, the reload makes me loose all the data frames and previous work done.
I applied a workaround by Avra:
with a checkbox. Yep, it is not perfect for my design or UX, but the thing works now. The user can change parameters and have new graphs.
I have a problem with my app; My app generates graphs, I can change the parameters that generate the graph. Those parameters I have in a selectbox and in a checkbox but every time I change them, the app restarts and stops showing the previous graph returning to the top of the page.
This is what the parameters look like:
Streamlit reruns with every interaction by design. It won’t behave like a terminal where things you write get added with each rerun; it will just start from scratch and run (with a memory of how you’ve changed the widgets).
If you share enough code to show the whole picture, I’m sure you can get additional direction.
Thanks for stopping by! We use cookies to help us understand how you interact with our website.
By clicking “Accept all”, you consent to our use of cookies. For more information, please see our privacy policy.
Cookie settings
Strictly necessary cookies
These cookies are necessary for the website to function and cannot be switched off. They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences, logging in or filling in forms.
Performance cookies
These cookies allow us to count visits and traffic sources so we can measure and improve the performance of our site. They help us understand how visitors move around the site and which pages are most frequently visited.
Functional cookies
These cookies are used to record your choices and settings, maintain your preferences over time and recognize you when you return to our website. These cookies help us to personalize our content for you and remember your preferences.
Targeting cookies
These cookies may be deployed to our site by our advertising partners to build a profile of your interest and provide you with content that is relevant to you, including showing you relevant ads on other websites.
great !
Fanilo
. This helps us prioritize and figure out how to best tackle this problem. We try to have all feature requests on Github, so we don’t need to comb through thousands of posts on the forum for planning.
