You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now when you flip back and forth between pages, selections of widgets in forms are not persisted. Ditto goes for saving the streamlit session to disk (new functionality around 2/23/24) in order to be consistent with the page-switching behavior.
At least, perhaps, put in a warning when there is form data that is not being saved, at least for session state saves.
May have to employ something like the streamlit_dataframe_editor class in order to do this.
Another option, probably the best option, would probably be to not use forms at all. They are probably being used because otherwise the page would take a long time to reload. However, a general principle we should probably employ is to hide long-taking processes on pages behind buttons (putting the long-taking process in a callback to the button). This would also ensure that the entire app is maximally snappy and ensure every page always loads quickly. When a user clicks a button (e.g., to run a workflow or display a heavy Plotly graphic), then they should expect a longer-taking process, so that would not be a problem.
Existing examples are currently in the Gater (plotting the new phenotypes) and in running the SIT workflow.
The text was updated successfully, but these errors were encountered:
Right now when you flip back and forth between pages, selections of widgets in forms are not persisted. Ditto goes for saving the streamlit session to disk (new functionality around 2/23/24) in order to be consistent with the page-switching behavior.
At least, perhaps, put in a warning when there is form data that is not being saved, at least for session state saves.
May have to employ something like the streamlit_dataframe_editor class in order to do this.
Another option, probably the best option, would probably be to not use forms at all. They are probably being used because otherwise the page would take a long time to reload. However, a general principle we should probably employ is to hide long-taking processes on pages behind buttons (putting the long-taking process in a callback to the button). This would also ensure that the entire app is maximally snappy and ensure every page always loads quickly. When a user clicks a button (e.g., to run a workflow or display a heavy Plotly graphic), then they should expect a longer-taking process, so that would not be a problem.
Existing examples are currently in the Gater (plotting the new phenotypes) and in running the SIT workflow.
The text was updated successfully, but these errors were encountered: