st.toast alerts without rerun duplicates: choosing persistence and dedup strategy
21.5K reputation · 08 Feb 2021, 17:09 UTC
Goal
I want to surface useful in-app alerts in a Streamlit app using st.toast, without creating notification noise. The alerts are low-priority status events (for example, a background data refresh completing), so they should not block the script, but they also should not reappear every time the user touches an unrelated widget.
Constraints and uncertainty
From the documentation, st.toast is transient and non-blocking, but the script reruns top to bottom on every interaction, so a toast tied to a condition will fire again on each rerun unless deduplicated. st.session_state flags seem to be the standard guard, but that gives once-per-session behavior, which may hide a condition that clears and later becomes true again. For anything that must stay visible until acknowledged, st.warning or st.error would persist inline instead, so there is a real tradeoff between visibility and noise. There also appears to be no documented way to push alerts outside an active session. Assume a recent Streamlit version; the st.toast signature should be checked against the installed release.
Questions
- What is the recommended pattern to fire a toast exactly once per condition occurrence rather than once per session?
- When several events occur in one rerun, should they be batched into a single summary toast, and does stacking make per-item toasts unusable?
- Which conditions justify switching from st.toast to a persistent st.warning/st.error element?