Keyed widget state persistence - discussion, possible fixes

Show the Community!
3

My instinct: avoid a breaking change that sets the default behavior to keep keys after a widget is destroyed. Bad scenarios I imagine:

  1. I can imagine having widgets generated in a loop or having some real-time app that is doing a lot of refreshes. If this is combined with having something like a random or time-stamped key to forcibly destroy and recreate widgets over and over, it will create a mess of session state. I know there have been instances on the forum where I have advised “you can set the key to include a timestamp so that it is forcibly destroyed and starts over from the beginning.”

    Here’s an example where that advice came up: Input widgets inside a while loop

    Maybe this was bad advice and manually setting the value of the key would be better, but it is one approach that could have been taken that relies on the current default cleanup. However, if there are a lot of widgets involved, a batch prefix in the form of a timestamp for each key is a really easy way to reset all of them.

  2. There may be cases when different pages use the same key on widgets that are not intended to connect back up. This may especially be the case if each page is a kind of template or variation meant to start fresh, be independent, and maybe have some consistent naming conventions. I can’t imagine how many people were not trying to connect widgets on different pages and have overlap of simple names for keys.

    Certainly there would have a be a carve out for st.button, st.download_button, st.file_uploader, and st.form which cannot be set using st.session_state.

    A recent thread in the forums discussed creating an aggregating app form individual, standalone apps. I would think this case would be ripe to have a conflict with keys forcibly maintained across pages: Multi-page App from Single Apps

  3. This is probably a moot point as “does not apply” or “easily not included,” but I’d want to confirm the case for generated keys. If you did do a breaking change, I imagine by necessity that it could only apply to manually assigned keys and never generated keys. Currently, we get an error with the following on one page:

    st.text_input('A')
st.text_input('A')

    DuplicateWidgetID: There are multiple identical st.text_input widgets with the same generated key.

    If any generated key was kept (extending the unique label restriction across all pages in the absence of a distinct key), I think it would cause a lot of breakage with the same kinds of widgets having the same labels on different pages and no intent to connect them.

For me the default cleanup behavior makes a lot of sense as a safe way to avoid clogging up the system. Sure, it might not be the first thing people think of when they want to carry info between pages, but I think the “clean by default” might be a little underappreciated in favor of the current problem that draws our attention. Hence, I like adding another keyword to change what/how much is exempted from cleanup.

If you want to get super slick about it,

  1. keep the default behavior,
  2. add a keyword to one-off change the behavior,
  3. and provide an option in the app configuration file to set a different default for the whole app.
3 Likes