Move st.app_state further up in the roadmap

[u3Izx9ql7vW4]

Checklist

• I have searched the existing issues for similar feature requests.
• I added a descriptive title and summary to this issue.

Summary

State management has been by far the most common complaint about Streamlit online when I was comparing various dashboarding libraries. There is a mention of st.app_state in the roadmap, which is great, but there is no timeline of when it will go into development / be finished. I would like to suggest that this st.app_state be given a definite date, ideally as soon as possible.

I also saw that NoSQL database mentioned, I would suggest considering pickling the entire st.session_state. It'll be faster and more robust in almost every way -- there is no network trip to the database, no need to occupy an extra process running the database, no lookups, and minimal serialization. It also works for any data type, and as far as speed goes for large binaries, what you wouldn't pickle you wouldn't store in a NoSQL database anyway.

I would further propose that as opposed to having to register data in st.session_state, have all state data be registered by default. This comes from personal experience where my code is bloated by 50-100% from having to save and load every single thing into session_state, and it's usually the exception that I have a truly stateless component.

Why?

Given how many people the app reruns issue impacts, and literally everyone handling their own way, it would seem logical to make this a priority. From looking at the up-coming todos, I think st.app_state has the highest impact, as measured by

no. of hours saved * no. of streamlit users affected / development hour

For example, I have a custom component dedicated to state management, which saves and loads yaml, among other things, and I'm almost certain that I'm not the only one. And as mentioned, almost 50% of my code is related to checking, saving to, or loading from st.session_data, and I've spent more time than I want on thinking about caching.

How?

I'm open to however it's planned to be developed, but it seems wrong to me that an app would rerun the script from top to bottom on every interaction as a foundation. But, I'm unfamiliar with how streamlit works under the hood, so what I say could be misguided.

Having developed in Angular and React, my two cents is to adopt some kind of model-view-controller (MVC) framework in the background. Generally events / interactions should only propagate up to the component it affects, and no further. My understanding is that these components are usually modelled as trees.

How this can be done without changing the API is more difficult, and above my pay-grade.

Additional Context

To me st.session_state and various caching mechanisms are bandaid solutions that puts off dealing with the much larger issue related to the app rerunning from top to bottom on every interaction. In other words, if streamlit was stateful by default, there wouldn't be a need for session states and far fewer occasions where caching is needed. I'm not sure the proposed st.app_state is intended to address that underlying issue of the app rerunning on each interaction, as at face value it sounds like what will hopefully be the last fix -- which is ok if that's the best we can get.

[github-actions]

To help Streamlit prioritize this feature, react with a 👍 (thumbs up emoji) to the initial post.

Your vote helps us identify which enhancements matter most to our users.