4 Streamlit's execution model

Streamlit runs your Python script from top to bottom to produce the app’s frontend. Whenever the page needs to change—such as when a user clicks a button, checks a checkbox, changes a text input, selects from a dropdown, or moves a slider—Streamlit reruns the entire script.

The original app stored tasks in a regular Python variable:

task_list = []

Because Streamlit reruns the whole script after each interaction, this line reset task_list to an empty list every time. As a result, previously added tasks disappeared when the user added another task, clicked a checkbox, or clicked a button.

st.session_state stores values that should persist across Streamlit reruns during a user’s session. It acts much like a dictionary and is useful for remembering app state, such as a task list, a counter value, or user selections.

Example:

if "task_list" not in st.session_state:
    st.session_state.task_list = []

task_list = st.session_state.task_list

If you set a session state value unconditionally on every run, you will overwrite the saved value each time the app reruns. The check ensures initialization happens only once, usually on the first run of the session.

if "number" not in st.session_state:
    st.session_state.number = 0

Without this check, number would be reset to 0 every time the app reran.

Each task is represented using a Python dataclass with two fields: a task name and a completion status.

from dataclasses import dataclass

@dataclass
class Task:
    name: str
    is_done: bool = False

The name field stores the task text, and is_done stores whether the task has been completed. It defaults to False.

Streamlit uses widget keys to identify widgets such as buttons, checkboxes, and text inputs. If multiple widgets have the same label or otherwise appear identical, Streamlit may generate duplicate internal keys and raise an error.

For example, multiple “Delete” buttons need unique keys:

if delete_col.button("Delete", key=f"delete_{idx}"):
    delete_task(idx)

Similarly, checkboxes can use keys like task_0, task_1, and so on, so duplicate task names do not cause widget-key conflicts.

st.rerun() tells Streamlit to stop the current script run and immediately start again from the top. It is useful when app state has changed after some display logic has already run, and you need the UI to reflect the updated state right away.

if delete_col.button("Delete", key=f"delete_{idx}"):
    delete_task(idx)
    st.rerun()

The delete button was inside the loop that displayed tasks. When the user clicked “Delete,” Streamlit reran the script and displayed the task before the deletion function was called. The task list was updated, but the UI had already been rendered using the old list.

Calling st.rerun() immediately after deleting the task fixed the lag by forcing Streamlit to rerun the script and render the updated task list.

An infinite rerun loop can happen when st.rerun() is called every time the script runs, even when no state change is needed. In the chapter, this occurred when checkbox logic called st.rerun() in both the checked and unchecked branches.

The fix was to call st.rerun() only when the checkbox value actually changed the task’s stored status:

checked = task_col.checkbox(label, task.is_done, key=f"task_{idx}")

if checked and not task.is_done:
    mark_done(task)
    st.rerun()
elif not checked and task.is_done:
    mark_not_done(task)
    st.rerun()

Completed tasks are displayed with a markdown strikethrough by wrapping the task name in double tildes when task.is_done is True:

label = f"~~{task.name}~~" if task.is_done else task.name

The app also uses st.metric to show completion progress:

total_tasks = len(task_list)
completed_tasks = sum(1 for task in task_list if task.is_done)
metric_display = f"{completed_tasks}/{total_tasks} done"

st.metric("Task completion", metric_display, delta=None)