Let’s use the following code to see a little example in action and understand more. Start by writing the following code:
Figure 15.9: Session State in code
The idea behind Session State is simple and genial: Streamlit always runs from top to bottom on every iteration, so we check whether a variable of our interest (count in the example) has already been initialized in st.session_state. If it is not initialized yet, we initialize it to a specific value (0 in our case); otherwise, we don’t do anything.
So, st.session_state is just a kind of collection that saves variables we don’t want to initialize every time.
The preceding code is very easy. Here’s a breakdown:
- On line 13, we check whether the count variable is not in session_state; in this case, we initialize it to 0
- On line 19, we create a button to increment the count variable and we perform this operation using st.session_state.count; in this way, we remember the count variable’s value
- On line 24, we do the same, but decrementing the count variable
- Finally, on line 28, we visualize a little message on the screen showing the count variable value
This is the result in the browser:
Figure 15.10: Session State in action
Please verify that every time you click on the Increment or Decrement button, the value of Count is automatically updated.
The code in Figure 15.9 demonstrates the persistence of values across reruns. However, let’s explore a more intricate scenario. In Streamlit, it is feasible to assign callbacks to various widgets, such as st.button or st.slider. This is achieved by utilizing the on_change argument, allowing for more advanced interactivity and functionality.
A callback, often referred to as a call-after function, is a segment of executable code that is provided as an argument to another piece of code. This arrangement anticipates that the receiving code will execute the callback at a specified moment. Typical scenarios for such execution include user interactions such as clicking a button or adjusting a slider – essentially, whenever a change is detected.
Utilizing Session State enables the management of events linked to modifications in a widget or button clicks through callback functions. This implies that when a callback function is associated with a widget, any alteration in the widget initiates a specific sequence: the callback function is executed first, followed by a top-to-bottom execution of the application.
Let’s see callbacks in action:
Figure 15.11: Callbacks in code
Here’s a breakdown of the code in Figure 15.11:
- On line 32, we define a callback function named update_first. This function updates the value of the second variable contained in the session_state widget to the value of the first variable always stored in the session_state widget.
- On line 35, we define a second callback function that is exactly the same as the first one, but updates the value of the first variable according to the value of the second one.
- On lines 39 and 40, we introduce two text_input widgets. Among their arguments, as usual, we can find a label and a key, but this time there is something new: on_change.
Here, the callbacks enter action when a change happens in the widgets (so, when some text is inserted) when the update_first function is executed at line 39 and the update_second function is executed on line 40.
In this way, we create two widgets with mirrored values. This is the result in the browser:
Figure 15.12: Result of the callback action
As we can see, every time we insert text into the first input box, the second one is updated, and vice versa.
Session State is perhaps one of the most powerful features of Streamlit. Please learn carefully how to leverage it.
Let’s now see the advantages offered by customizable subdomains.
