Session State Introduction

[mathcatsand]

I created a rough draft video showing an introduction to session state. I plan to re-record it with better audio and editing, but I wanted to get community feedback before I invested in a more polished presentation.

The video is aimed toward users who have either read through documentation already, or walked through their first app creation in another basic tutorial. Many questions in the Using Streamlit forum seem to boil down to details about session state, so these are the details I was figuring out in that first week or two of playing around with Streamlit.

(Video is processed up to 720p at time of posting. Higher resolution expected within a couple hours. )

Any thoughts feedback before I record the final version?

Streamlit Session State Introduction

[asehmi]

Super clear to me. I’m sure it’ll be very useful. (Not sure the assignment of ss.c2 will work on the first run as the key c2 will not have been created… best check that.)

[mathcatsand]

I know when I’m messing around with session_state (especially when making live edits) I can get the warning about a widget getting created. I’m trying to recreate it to get the exact message, but now that I’m trying it’s not breaking for me. I’m not having a problem just creating a key before the widget and having it initialize with that value, though.

In fact, Streamlit must have some ‘shadow memory’ besides what’s explicitly available by key. I’m getting a checkbox to remember its state even if I forcibly delete its key before rendering it (though it forgets if I build in extra interactions/page refreshes while its not rendered).

Looks like I have something to experiment with to put into a part 2.

[asehmi]

In my opinion describing the “best practice” approach rather than the nuances of edge cases will help 90% of your audience. Though I personally like the details, they’re not useful for most.

If you’re interested, I wrote a gist explaining some aspects of this topic here. I like your explanation better.

Thanks,
Arvindra

[Shawn_Pereira]

Hi @mathcatsand, just started going through your video. Informative, with examples - should help viewers realize how state values change during a refresh cycle.

I have a teeny suggestion though: however aesthetically possible, group your widgets into columns, so that the font in the right pane can be consequently increased. It will help those who view your video on mobile devices.

The other suggestions (audio, etc.) Are already part of your to-do list.

Cheers

[PeterG]

Thanks @mathcatsand (and @asehmi for your gist referenced above). Both helped a lot with a session state issue that I’m grappling with. I found the video very practical and a great introduction to the dynamics of session state (beyond the absolute basics). It would have saved me a lot of time when I started using session state. Regarding feedback before you record a final version: I think this version works perfectly well as a final version!

Thanks,
Peter

[Vital-Fernandez]

Thank you, thank you very much @mathcatsand for this guide. One question if I may: Is the “_hold” structure you used the standard approach in multi-page apps to keep the widget values once you revisit a page? Thanks again!!

[mathcatsand]

I don’t know if it’s any kind of standard, it’s just what I figured was logical since keys go away along with their widgets.

I’ve seen two approaches taken:

1. As I did in the video, make a secondary set of keys not tied directly to any widget so they persist for the entire session without worry of any particular widget being rendered or not.
2. Create a copy-paste function at the top of every page to “keep them alive.” For a list key_keeper of widget keys you want to protect from deletion, put at the top of each page:

for key in key_keeper:
    st.session_state[key] = st.session_state[key]

I’ve seen the latter frequently around the forum, but my personal style leans toward the former.

It would be nice if widgets had optional arguments to protect their keys from deletion within Streamlit. I get that deleting widget keys by default is good for cleanup, but this seems like a frequent enough use-case that it’d be a good feature. (I haven’t looked on GitHub to see if its posted as a feature request already. I should look…)

[Vital-Fernandez]

Thank you very much!