I just composed my first Streamlit program.
It uses 3 pages. I am using session_state to preserve widget states between page switches.
It works just fine locally. But when I deploy it, session_state does not seem to be working.
When I switch pages, the widgets did not preserve their last state.
As I said, this is my first attempt in using Streamlit, so it is very well possible that I am doing something wrong.
Here is my code:
import streamlit as st
my_page = st.sidebar.radio('Page Navigation', ['Home', 'Slider', 'Contact'])
if 'slider1' not in st.session_state:
st.session_state.slider1 = 0
if 'check1' not in st.session_state:
st.session_state.check1 = False
def CB_Slider1():
#st.session_state.slider1 = slide1
pass
def home():
st.write("Welcome to home page")
st.checkbox("Check me", value=st.session_state.check1, key='check1')
if st.button("Click Home"):
st.write("Welcome to home page")
def slider():
#st.title('this is a different page. One with a slider.')
st.write("Welcome to the slider page")
slide1 = st.slider('this is a slider',min_value=0,max_value=15,value=st.session_state.slider1 ,key='slider1' )
slide1
def contact():
st.title("Welcome to contact page")
if st.button("Click Contact"):
st.write("Welcome to contact page")
if my_page == 'Home':
home()
elif my_page == 'Slider':
slider()
elif my_page == 'Contact':
contact()
I did some searching on these forums for some session_state related subjects.
I looked at some code snippets, but most date back from before session_state was integrated in Streamlit.
Nevertheless I found something that makes my above code work.
I just added this single line in the beginning of the script:
st.session_state.update(st.session_state)
In a pure Python program this makes no sense at all, but apparantly in Streamlit it does.
I would appreciate it if someone could explain the mechanics behind this. Why it makes a difference in Streamlit.
Also, I find it weird and confusing that Streamlit behaves differently when used locally or in the cloud ā¦
Anyway, here is my working code. I just added the above line, and am also displaying the session_state dict.
import streamlit as st
my_page = st.sidebar.radio('Page Navigation', ['Home', 'Slider', 'Contact'])
st.session_state.update(st.session_state)
if 'slider1' not in st.session_state:
st.session_state.slider1 = 0
if 'check1' not in st.session_state:
st.session_state.check1 = False
def home():
st.write("Welcome to home page")
st.session_state
st.checkbox("Check me", value=st.session_state.check1, key='check1')
if st.button("Click Home"):
st.write("Welcome to home page")
def slider():
st.write("Welcome to the slider page")
st.session_state
slide1 = st.slider('this is a slider',min_value=0,max_value=15,value=st.session_state.slider1 ,key='slider1' )
slide1
def contact():
st.title("Welcome to contact page")
st.session_state
if st.button("Click Contact"):
st.write("Welcome to contact page")
if my_page == 'Home':
home()
elif my_page == 'Slider':
slider()
elif my_page == 'Contact':
contact()
Have you confirmed that you are using the same version of Streamlit both locally and on Cloud? While st.session_state.update(st.session_state) might work, this is the first time Iāve ever seen that used, so I would not expect this to be the actual answer.
Have you confirmed that you are using the same version of Streamlit both locally and on Cloud?
That is indeed part of the explanation.
Being new to Streamlit, I installed it with a Conda install. I noticed (a few days later) that the version it installed was 0.84.
So indeed, the version I was running locally was 0.84 and the one online is currently 1.5.0 (1.5.1 locally).
That explains the difference I noticed in the behaviour of st.session_state between 0.84 locally and 1.5.0 in the cloud. Strangely enough, what I wanted to achieve (widget state preservation) worked on 0.84 but not on 1.5.0 . That was the origin of my confusion.
While st.session_state.update(st.session_state) might work, this is the first time Iāve ever seen that used, so I would not expect this to be the actual answer.
Well, the fact remains that the code snippet in my first post does not preserve widget states.
After adding the command st.session_state.update(st.session_state) widget states are preserved.
I hope you can understand my confusion because this command is pointless in a pure Python environment, yet it seems to make a lot of difference in a Streamlit environment.
I am new to Streamlit so I probably missed a lot of the history of the Streamlit development, but I think it is very important that users are informed that some Pythonic statements can behave un-Pythonic.
Or otherwise put, Streamlit does some things āunder the hoodā that go against the normal behaviour of Python code. Or atleast, have some side effects that are surprising if you do not know about them.
@okld and I had some discussion about this in thread:
It seems like thereās quite a few things wrapped up in this, so Iād like to separate the issues. As far as I can tell, youāre indicating that this doesnāt work in Streamlit the Python library as you would expect? This isnāt a difference between local environment and Streamlit Cloud?
By reading the linked forum discussion from @okld, it sounds like this is less around Streamlit doing āun-Pythonicā things, but rather this being an edge case weāve not planned for. Thatās where my comment of
While st.session_state.update(st.session_state) might work, this is the first time Iāve ever seen that used, so I would not expect this to be the actual answer .
comes from.
Ultimately, multi-page is something that is on our product roadmap, so with that hopefully this use case becomes much easier. For now, Iām not sure what to recommend to you.
It seems like thereās quite a few things wrapped up in this, so Iād like to separate the issues.
You are right. Let me try to summarize.
a) Regarding the topic of this thread (āSession_state does not seem to be working in the cloudā). This was caused by my mistake of having an older version of Streamlit (0.84) running locally, while in the cloud version 1.5.0 is running. The session_state behaviour was changed between versions, thatās why I saw my code behaving differently local and online, leading to my incorrect conclusion that session_state was ānot workingā in the cloud.
b) The object I was trying to achieve with my code (āA multi-page app with preservation of widget statesā) got mentioned in the thread, but is better discussed in other threads.
Ultimately, multi-page is something that is on our product roadmap.
Great to hear that the team is working to implement this in Streamlit. I am sure this will make a lot of Streamlit users very happy!
For now, Iām not sure what to recommend to you.
Iām reassured now. All will come together. Thanks for your reply!
Hello @RayJ and @randyzwitch
I am facing a similar issue that I have shared at This discussion
I have a multipage app that I am deploying to streamlit cloud.
In short, I have three pages in the app. Each page defines a set of session_state variables.
I am using component: streamlit-drawable-canvas in only one page of them.
In the pages that donāt use streamlit-drawable-canvas, everything seems working normally.
In the page that uses streamlit-drawable-canvas, once the code hits the part to use the component, streamlit doesnāt seem to find any of the session_state variables any more. The above link includes a snippet of the code I am using.
Needless to say, the app is working perfectly on local machine.
Any clues?
Thanks.
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.