Can someone explain this from release notes about session key of widgets and what is the impact on current apps

Using Streamlit
1

“Notable Changes

  • :key: To prevent widgets from resetting when you change a parameter, widgets are transitioning to an identity based only on their keys (if provided). The following widgets use only their key for their identity:”

I am not sure i understand this change fully and how it will impact the current version of the code that i have. comparing before and after behavior and what changes i might need to make in my code.

Apologies but i am not that savvy with session states etc.

thanks in advance.

2

In previous versions of Streamlit, the identity of a widget (its “ID”) was determined by a combination of factors:

  1. Its code location (file + line number)

  2. The widget label (e.g., button text)

  3. The key parameter (if provided)

:backhand_index_pointing_right: This meant that if you changed the label or moved the code, Streamlit would think it was a new widget → causing the widget state to reset.

:white_check_mark: Example Comparison

Old behavior (state resets easily)

import streamlit as st

st.title("Old behavior demo")

# No key, identity depends on label + position
name = st.text_input("Your name")  # key="username_input"
st.write("Hello,", name)

# If you change the label to "Enter your name"
# Streamlit sees this as a new widget → state is lost

:right_arrow: Changing "Your name" to "Enter your name" would reset the input value.

New behavior (key-based identity)

import streamlit as st

st.title("New behavior demo")

# Explicit key ensures stable identity
name = st.text_input("Your name", key="username_input")
st.write("Hello,", name)

# Even if you change the label to "Enter your name"
# As long as key="username_input" remains, the state is preserved

:right_arrow: With a fixed key, the widget state is stable, regardless of label changes or code refactoring.

You can understand the changes by placing the two scripts above in versions earlier than 1.49.0 and 1.50.0 respectively.

3

thanks for the detailed reply. so if i keep the key same and i use a variable in the label that changes dynamically, the session state will remain unchanged?

4

remain unchanged

5

It seems, however, that this change doesn’t fully work with the multiselect widget. Try doing a classical country city filtering, with an initial multiselect to filter a list of cities by selecting only a subset of countries. The second multiselect selects the final cities. If for some reason the country list changes, this will make the options parameter change for the second widget, I would expect this new change make the selection stay in place specially if I include a key and set the allow_custom_selections to true, but it is not the case, I need to backup the key preemptively up on every iteration else I will lose the list of already selected cities (even if I drop a country like Argentina and all my cities were from Japan)