1. Tasks are lost when the page reloads
2. Users can only manage one list at a time

In this tutorial, we’ll solve these problems by making tasks persistent using browser storage, and supporting multiple task lists by modifying the current callbacks.

Here’s a live display of the app you’ll learn to build (or click here):

Let’s dive in!

Part 1: Making tasks persistent

When we reload our current app, all tasks are reset to their initial state. This happens because Dash reinitializes all variables when the page reloads. To fix this, we need a way to save our tasks somewhere.

There are several options for persistence:

• Database (SQL, MongoDB, etc.)
• File system
• Browser storage

For simplicity, we’ll use browser storage through Dash’s built-in dcc.Store component. This component can save data in the browser’s:

• memory: Data is lost on page refresh
• session: Data persists until the browser tab is closed
• local: Data persists even after closing the browser

As we want to keep tasks over the time, local seems a perfect fit.

Note: using local means that the information is stored in the localStorage of the browser. It will stay as long as the user do not clean its browser / reset history.

1. Adding storage component

First, let’s modify our app to use dcc.Store. We’ll move our task list data into the store:

app.layout = dmc.MantineProvider(
    [
        dmc.Container(
            get_list_layout(),  # No data passed here anymore
            size=400,
        ),
        dcc.Store("list_data_memory", data=sample_list_data, storage_type="local"),
        dcc.Store("current_index_memory", data=sample_list_data[0]["index"], storage_type="local"),
    ]
)

We wrap our layout in a list to include both the container and store.

The functionget_list_layout() no longer receives data directly. Instead, a new callback will load the data from the list_data_memory directly to the components that need to be updated (list’ title, tasks, …).

Finally, we also add a current_index_memory to save the index of the currently displayed list.

2. Updating the layout functions

Our get_list_layout() function needs to change since it won’t receive data directly:

def get_list_layout():
    """ Returns the list of checkboxes """

    content = dmc.Paper(
        [
            dmc.Title(id="main_list_title", order=2),

            dmc.Container(
                id="main_task_container",
                px=0,
                mt="md",
                mb="md",
            ),

            dmc.Button(
                "Add a new task",
                id="new_task_button",
                style={"width": "100%"},
                variant="outline",
                color="gray",
            )
        ],
        shadow="sm",
        p="md",
        mt="md",
        radius="sm",
    )

    return content

As you can see, we removed the list_data parameter. Instead of populating the layout with data, we add IDs to the title and task container. We will populate them using callbacks reading from list_data_memory.

3. Adding update callback

Let’s build a callback to update our container when the stored data changes:

@app.callback(
    Output("main_task_container", "children"),
    Output("main_list_title", "children"),
    Input("list_data_memory", "data"),
)
def update_task_container(list_data):
    """ Updates the list of tasks and list title"""

    return get_tasks_layout(list_data["tasks_list"]), list_data["title"]

This callback listens for changes in our stored data and updates both the task list and list title. that way, we’re sure that the layout will be updated every time when list_data_memory changes.

We set the prevent_initial_call=False (implicity) because we actually want this callback to populate the layout using the stored data from local storage at loading time.

4. Modifying task callbacks

Now we need to update our task-related callbacks to work with stored data. Instead of directly modifying the layout, they’ll update the stored data:

@app.callback(
    Output("list_data_memory", "data", allow_duplicate=True),
    Input("new_task_button", "n_clicks"),
    State("list_data_memory", "data"),
    prevent_initial_call=True,
)
def add_task(n_clicks, list_data):
    """ Adds a task to the list """
    if not n_clicks:
        raise PreventUpdate

    # Create new task dictionary
    new_index = uuid.uuid4().hex
    new_task = {
        "index": new_index,
        "content": "",
        "checked": False,
    }

    # Add new task to the tasks list in memory
    list_data["tasks_list"].append(new_task)
    return list_data

The main changes are:

1. Output is now the store data instead of the container
2. We take the current store data as State
3. We modify and return the stored data

We’ll do the same for the remove task callback:

@app.callback(
    Output("list_data_memory", "data", allow_duplicate=True),
    Input({"type": "task_del", "index": ALL}, "n_clicks"),
    State("list_data_memory", "data"),
    prevent_initial_call=True,
)
def remove_task(n_clicks, list_data):
    """ Remove a task from the list """
    if not any(n_clicks):
        raise PreventUpdate

    task_index = ctx.triggered_id["index"]

    # Find and remove the task with matching index
    list_data["tasks_list"] = [
        task for task in list_data["tasks_list"]
        if task["index"] != task_index
    ]

    return list_data

Apart from the fact that we can persist the data, this way of updating a dcc.Store is a better, cleaner way than relying directly on the container. We have more control on the stored data, on its form and when it is updated.

5. Adding task update callback

We also need to handle updating task content and checked status:

@app.callback(
    Output("list_data_memory", "data", allow_duplicate=True),
    Input({"type": "task_checked", "index": ALL}, "checked"),
    Input({"type": "task_content", "index": ALL}, "value"),
    State("list_data_memory", "data"),
    prevent_initial_call=True,
)
def update_task_checked(checked_values, content_values, list_data):
    """Updates the checked state and content of tasks"""
    if not checked_values:
        raise PreventUpdate

    # Find the index position in our list of tasks
    task_index = ctx.triggered_id["index"]
    task_pos = [task["index"] for task in list_data["tasks_list"]].index(task_index)

    task_checked_value = checked_values[task_pos]
    task_content_value = content_values[task_pos]

    # Update the task values in list_data
    list_data["tasks_list"][task_pos]["checked"] = task_checked_value
    list_data["tasks_list"][task_pos]["content"] = task_content_value

    return list_data

6. Run the app

Now our tasks persist across page reloads! You can try it by adding some tasks and reloading this page, you tasks should still be here .

See the full code on Github or open the app.

Part 2: Supporting multiple lists

You will be surprised how easy it is now to handle the multiple list. As we have a store → layout scheme, we only need to modify the way that the data is structured and modify the layout to add this feature.

1. Updated data structure

First, let’s change our data structure to support multiple lists:

sample_list_data = [
    {
        "index": uuid.uuid4().hex,
        "title": "My Tasks",
        "tasks_list": [
            {
                "index": uuid.uuid4().hex,
                "content": "Task A",
                "checked": True,
            },
            # ... other tasks
        ],
    },
    {
        "index": uuid.uuid4().hex,
        "title": "Shopping list",
        "tasks_list": [],
    }
]

As you can see, we simply wrap the old dict inside a list, and add another example. We also anticipate and add a unique ID (index) because soon or later we will need to identify lists from each other.

2. Adding list navigation

Let’s add a sidebar for list navigation. Each list will be represented as a card with a title and a progression bar.

A new function get_list_navigation_layout will handle this:

def get_list_navigation_layout(list_data, current_index):
    """ Returns a list of lists titles and progressions """

    items = []

    for list_item in list_data:
        # Compute progression
        progress_value = get_progression(list_item)
        progress_color = "green" if progress_value == 100 else "blue"

        # Build card element
        elem = dmc.Paper(
            html.A(
                [
                    dmc.Title(list_item["title"], order=4, mb="sm"),
                    dmc.Progress(value=progress_value, color=progress_color),
                ],
                id={"type": "list_button", "index": list_item["index"]},
                style={"cursor": "pointer"},
            ),
            p="xs",
            mb="sm",
            withBorder=True,
            className="active" if current_index == list_item["index"] else ""
        )
        items.append(elem)

    return items

def get_progression(list_item):
    """ Computes the progression of a list """
    tasks = list_item["tasks_list"]
    if len(tasks) == 0:
        return 0
    return len([task for task in tasks if task["checked"]]) / len(tasks) * 100

We simply iterate over the lists in list_data. For each list, we compute the progression (the progress bar turns green at 100% instead of blue) and make the cards with title and progress bar.

Notice that we wrapped the content inside a html.A button. That way, we make the card clickable and we will be able to create a callback listening for clicks (n_clicks) on the card component.

The current_index parameter will store the index of the list we’re currently displaying. We use it to set the CSS class “active” to this list, making it focused compared to the others.

/* Filepath: assets/style.css */
/* ... (previous code) ... */

#list_navigation_layout > div {
    opacity: 0.7; 
}

/* Opacity is a good way to emphasize some elements */
#list_navigation_layout > div.active {
    border-color: black;
    opacity: 1.0;
} 

We also need a “New list” button:

def get_new_list_button():
    return dmc.Button(
        "New list",
        id="new_list_button",
        style={"width": "100%"},
        color="black",
        mt="md",
        mb="md"
    )

3. Updated app layout

Finally, we use DMC’s grid system to create a two-panel layout:

app.layout = dmc.MantineProvider(
    [
        dmc.Container(
            dmc.Grid(
                [
                    dmc.GridCol(
                        [
                            get_new_list_button(),  # The new list button
                            dmc.Container(          # This container will be updated dynamically
                                id="list_navigation_layout",
                                px=0,
                            )
                        ],
                        span=4,
                    ),
                    dmc.GridCol(
                        get_list_layout(),
                        span="auto",
                        ml="xl"
                    ),
                ],
                gutter="md"
            ),
            size=600,
        ),
        
        # The stored data in localStorage
        dcc.Store("list_data_memory", data=sample_list_data, storage_type="local"),
        dcc.Store("current_index_memory", data=sample_list_data[0]["index"], storage_type="local"),
    ]
)

The left panel serves as a navigation sidebar, displaying all available lists with their progress bars. The right panel shows the tasks of the currently selected list, maintaining our familiar task interface but adding an editable title and a list deletion option.

Here’s the interactive version of the new layout:

See the full code on Github or open the app.

In the next section, we’ll add the necessary callbacks to make this layout interactive.

4. List management callbacks

With multiple lists to manage, we need callbacks to handle list-level operations.

The list switching callback responds to clicks in the navigation sidebar, updating current_index_memory to display the selected list:

@app.callback(
    Output("current_index_memory", "data", allow_duplicate=True),
    Input({"type": "list_button", "index": ALL}, "n_clicks"),
    prevent_initial_call=True,
)
def switch_list(n_clicks):
    """ Changes the current displayed list"""
    if not any(n_clicks):
        raise PreventUpdate

    list_index = ctx.triggered_id["index"]
    return list_index

When users create a new list, the add_list callback adds it to our collection and automatically makes it the current list by updating current_index_memory.

@app.callback(
    [
        Output("list_data_memory", "data", allow_duplicate=True),
        Output("current_index_memory", "data"),
    ],
    Input("new_list_button", "n_clicks"),
    State("list_data_memory", "data"),
    prevent_initial_call=True,
)
def add_list(n_clicks, list_data):
    """ Add a new list and display it"""
    if not n_clicks:
        raise PreventUpdate

    new_index = uuid.uuid4().hex
    new_list = {
        "index": new_index,
        "title": "New list",
        "tasks_list": [],
    }

    list_data.append(new_list)
    return list_data, new_index

You’ll notice how the code is similar to the add_task callback.

List deletion works in two steps: first showing a confirmation modal, then removing the list if confirmed. That way, the UX (User Experience) is better and avoids mistakingly deleting lists!

@app.callback(
    Output("del_list_modal", "opened"),
    [
        Input("del_list_button", "n_clicks"),
        Input("del_list_modal_confirm_button", "n_clicks"),
    ],
    prevent_initial_call=True,
)
def delete_modal_open_close(n_clicks, n_clicks2):
    """ Open or closes modal """
    if not n_clicks:
        raise PreventUpdate

    if ctx.triggered_id == "del_list_modal_confirm_button":
        return False

    return True

@app.callback(
    [
        Output("list_data_memory", "data", allow_duplicate=True),
        Output("current_index_memory", "data", allow_duplicate=True),
    ],
    [
        Input("del_list_modal_confirm_button", "n_clicks"),
        State("list_data_memory", "data"),
        State("current_index_memory", "data"),
    ],
    prevent_initial_call=True,
)
def delete_list(n_clicks, list_data, current_index):
    """ Updates the current list title """
    if not n_clicks:
        raise PreventUpdate

    # Remove the current list
    i = get_pos_from_index(list_data, current_index)
    del list_data[i]

    # Focus again on the first index if there are notes
    current_index = list_data[0]["index"] if len(list_data) > 0 else None
    return list_data, current_index

We used ctx.triggered_id to differentiate whether we needed to open or close the modal. It’s a simple way to update the same component without relying on allow_duplicate=True and making two separate callbacks.

Note: you might wonder why the Outputs and Inputs are now wrapped inside lists: [Output(…), Output(…)]. In this case, this is just syntax sugar that helps visualizing what are the inputs / outputs easily. I often do this as the outputs or inputs grows.

We’ve added a helper function get_pos_from_index that simplifies finding lists in our data structure – it’s used throughout our callbacks to ensure we’re modifying the correct list:

def get_pos_from_index(dict_list, index):
    """ Gets position of dict with matching index in a list
			  Example:
	      * get_pos_from_index([{"index": "abc"}, {"index": "def"}], "def")  
	      * returns 1
    """
    for i, elem in enumerate(dict_list):
        if elem["index"] == index:
            return i
    return None

The helper work both for lists and for tasks.

5. Updated task callbacks

Finally, we need to update our task callbacks to work with the currently displayed list (using current_index_memory):

@app.callback(
    Output("list_data_memory", "data", allow_duplicate=True),
    [
        Input("new_task_button", "n_clicks"),
        State("list_data_memory", "data"),
        State("current_index_memory", "data"),
    ],
    prevent_initial_call=True,
)
def add_task(n_clicks, list_data, current_index):
    """ Adds a task to the list """
    if not n_clicks:
        raise PreventUpdate

    # Create new task dictionary
    new_index = uuid.uuid4().hex
    new_task = {
        "index": new_index,
        "content": "",
        "checked": False,
    }

    # Add new task to the tasks list in memory
    i = get_pos_from_index(list_data, current_index)
    list_data[i]["tasks_list"].append(new_task)

    return list_data

Similar updates are needed for the remove and update task callbacks. The key change is using get_pos_from_index() to find the current list in our data and updating it.

6. Run the app

Here is the final result. Try switch from a list to another, add list, remove, modify tasks… And reload the page!

Here’s the interactive version of the new layout:

See the full code on Github or open the app.

You can also download the entire project below:

Conclusion

Throughout this tutorial, we’ve taken our basic task list and transformed it into a more powerful application. We could go even further: adding user login/register, share task lists, etc. Feel free to implement them on your side!

In this tutorial we’ve covered key concepts:

• Using browser storage with dcc.Store
• Managing complex state across multiple components
• Building modular layouts with DMC Grid
• Handling nested data structures in callbacks

In the final part of this series, we’ll look at improving performance using Dash’s Patch system.

You can find the complete code for this tutorial on Github: https://github.com/Spriteware/todo-app-python-dash

I hope you enjoyed this tutorial.

You can ask questions on the associated topic on Plotly’s community forum: here.
Be sure to subscribe to the newsletter to see the next articles!

L’article Build a To-Do app in Python with Dash (part 2/3) est apparu en premier sur dash-resources.com.

The tutorial is in three parts:

1. Setup the layout, handle a minimal task list (part 1 – this article)
2. Handle multiple lists and save tasks on page reload (part 2)
3. Improve scalability and performance with Patch (part 3)

At the end of this article, you’ll know how to build the following To-Do app with Dash python:

Let’s go!

Introduction to Dash Mantine Components

Before we dive in, let’s understand what Dash Mantine Components (DMC) offers us. DMC is a component library that provides pre-built React components with a modern design system. It includes layout helpers (e.g. grid systems, centered container, …) and out-of-the-box components (e.g. Modal, Radio Button, Slider, etc.)

Some key components we’ll use:

• dmc.Container: A centered container with max-width
• dmc.Paper: A white background container with optional shadow
• dmc.Grid and dmc.GridCol: Flexbox-based grid system
• dmc.Button, dmc.Checkbox, dmc.ActionIcon: Interactive components

DMC uses several spacing and positioning attributes:

• mt: margin-top (e.g., mt="md" for medium margin-top)
• mb: margin-bottom
• px: padding on x-axis (left and right)
• p: padding on all sides
• Size values: “xs”, “sm”, “md”, “lg”, “xl” or numeric pixels

This will be useful for the rest of the article. If you encounter something you don’t understand, just go back here or search the component in DMC documentation.

Step 1: Setting up the layout

1. Data structure

Let’s start by defining how we’ll store our task data. This will actually help us shape the layout.

We want to create and save tasks. Each task should have a text content, and a checkbox status. That means having something like:

sample_list_data = {
    "title": "My Tasks",
    "tasks_list": [
        {
            "content": "Task A",
            "checked": True,
        },
        {
            "content": "Task B",
            "checked": False,
        },
        {
            "content": "Task C",
            "checked": False,
        },
    ],
}

From this structure, we can build the layout function to display tasks.

2. Creating reusable layout functions

A key aspect of our design is creating separate functions for each part of the layout. This isn’t just for code organization – it’s crucial for the dynamic nature of our app. Later, when we add or remove tasks, we’ll need to recreate portions of the layout dynamically. By having these functions, we can easily generate new task elements or update existing ones.

Let’s start with a function to render a single task using DMC’s Grid system:

def get_task(task_dict):
    """ Returns a single task layout """
    text = task_dict["content"]
    checked = task_dict["checked"]

    content = dmc.Grid(
        [
            # Checkbox column
            dmc.GridCol(
                dmc.Checkbox(
                    checked=checked,
                    mt=2  # Align checkbox vertically
                ),
                span="content"  # Take only needed space
            ),
            # Task text column - Using Input for editability
            dmc.GridCol(
                dmc.Text(  # Wrap in Text component for consistent styling
                    dcc.Input(
                        text,
                        className="shadow-input",  # Custom styling for input
                        debounce=True              # For callbacks
                    )
                ),
                span="auto"  # Take remaining space
            ),
            # Delete button column
            dmc.GridCol(
                dmc.ActionIcon(
                    DashIconify(icon="tabler:x", width=20),
                    variant="transparent",
                    color="gray",
                    className="task-del-button"
                ),
                span="content"
            ),
        ],
        className="task-container"
    )

    return content

We used dmc.Grid to easily get a 3 column structure. The first column has the checkbox, the second the text content, and the third has the delete task button.

You might wonder why we use a dcc.Input wrapped in a dmc.Text component. The idea is that we want to modify the text just by clicking on it. The most similar example is the “contenteditable” elements in HTML : but they aren’t available in Dash.

Instead, we will style the app with some CSS to make the input look like normal text when it is not focused (i.e. being modified).

Note: the debounce attribute is used to trigger the input “update” event when the user finishes typing, not every time a key is pressed. In this case, it offers a better user experience.

3. Creating the tasks list and main container

Now let’s create a function to render all tasks. It’s simply the for loop over the get_task function:

def get_tasks_layout(tasks_list):
    """ Returns the list of tasks """
    tasks = []
    for task_dict in tasks_list:
        task_layout = get_task(task_dict)
        tasks.append(task_layout)
    return tasks

We’ll wrap everything in a main container with a title and “Add a new ask” button:

def get_list_layout(list_data):
    """ Returns the list container with title and tasks """
    tasks_layout = get_tasks_layout(list_data["tasks_list"])

    content = dmc.Paper(
        [
            dmc.Title(list_data["title"], order=2),

            # Tasks container
            dmc.Container(
                tasks_layout,
                id="main_task_container",
                px=0,  # No horizontal padding
                mt="md",  # Medium margin top
                mb="md",  # Medium margin bottom
            ),

            # Add task button
            dmc.Button(
                "Add a new task",
                id="new_task_button",
                style={"width": "100%"},
                variant="outline",
                color="gray",
            )
        ],
        shadow="sm",  # Light shadow
        p="md",       # Medium padding
        mt="md",      # Medium margin top
        radius="sm",  # Slightly rounded corners
    )

    return content

4. Styling with CSS

DMC already brings a set of default stylesheet, which make us gain a lot of time. But as said previously, we want our we want our task inputs to look clean and minimal, with appropriate visual feedback for user interactions:

So we create a style.css file in the assets/ folder. This will be loaded automatically by Dash:

/* 
 * Filepath: ./assets/style.css 
 */

.shadow-input {
    display: inline-block;
    width: 100%;
    margin: 0;
    border: 1px solid black;
    border-color: transparent;
    border-radius: 5px;
}
.shadow-input:hover {
    border-color: gray;
}

.shadow-input:active, .shadow-input:focus {
    border-color: black;
}

.task-container:has(.mantine-Checkbox-root[data-checked]) .mantine-Text-root input {
    text-decoration: line-through;
    color: gray;
}

.task-del-button:hover {
    color: red;
}

This CSS does several things:

1. Makes inputs blend seamlessly into the layout with transparent borders
2. Shows subtle borders on hover and focus for better UX
3. Applies strikethrough styling to checked tasks
4. Adds a red hover effect to delete buttons

A key design decision here is handling the strikethrough effect with CSS rather than callbacks. By using the :has() selector to detect checked checkboxes, we can apply the strikethrough style directly in CSS. This is more efficient than using a callback, as it eliminates unnecessary round-trips to the server and provides instant visual feedback.

5. Running the app

Now let’s put everything together and start our application:

import dash_mantine_components as dmc
from dash import Dash, _dash_renderer, dcc
from dash_iconify import DashIconify
_dash_renderer._set_react_version("18.2.0")  # for mantine

# sample_list_data = ...

## Layout functions:
# get_task()
# get_tasks_layout()
# get_list_layout

app = Dash(__name__)

app.layout = dmc.MantineProvider(
    dmc.Container(
        get_list_layout(sample_list_data),
        size=400,  # Container width
    )
)

# Start the server
if __name__ == '__main__':
    app.run_server(debug=True)

When you run this code, you’ll have a basic task list application without interactivity yet:

See the full code on Github or open the app.

Now that we have our layout defined, we can make it interactive with callbacks.

Step 2: Adding interactivity with callbacks

Now comes the interesting part. We need to make our tasks interactive – we need to handle creating, reading, updating, and deleting tasks (CRUD operations). However, we face an interesting challenge: how do we handle callbacks for elements that don’t exist when the app starts?

In regular Dash callbacks, you must define both inputs and outputs statically – they need to exist when the app initializes. This works fine for static elements like a single button or dropdown. But in our task app, we’re dynamically adding and removing tasks! These elements don’t exist when the app starts running.

This is where pattern-matching callbacks come in. Instead of targeting specific IDs like “button-1” or “task-input-2”, pattern-matching callbacks let us define patterns that match multiple components, even ones created after the app starts running. They work by using a dictionary-based ID system and special selectors like ALL.

For example, compare these two approaches:

# Regular callback - Only works for a specific, existing button
@app.callback(
    Output("static-div", "children"),
    Input("submit-button", "n_clicks")
)

# Pattern-matching callback - Works for ANY button matching the pattern
@app.callback(
    Output({"type": "result", "id": ALL}, "children"),
    Input({"type": "submit", "id": ALL}, "n_clicks")
)

The pattern-matching version uses a dictionary for the ID with two keys:

• “type”: Groups similar components (like all submit buttons)
• “id”: Uniquely identifies each instance

Now we can write a single callback that handles all tasks of the same type, even ones created dynamically after the app starts! When we add a new task with ID {"type": "task", "id": "123"}, the callback will automatically work for it.

This is perfect for our task app where we need to add and remove tasks dynamically. Let’s continue.

Learn more on Pattern-Matching callbacks from the Dash plotly documentation: https://dash.plotly.com/pattern-matching-callbacks

1. Adding unique identifiers

As Pattern-Matching callbacks need a unique id, we need to modify our data structure to include unique identifiers for each task. Let’s add an index field using UUID :

import uuid

sample_list_data = {
    "title": "My Tasks",
    "tasks_list": [
        {
            "index": uuid.uuid4().hex,  # Add unique identifier
            "content": "Task A",
            "checked": True,
        },
        # ... other tasks
    ],
}

Example UUID: f4da57942cec46b7ba448c88fad11996. We could as well have used integers. It doesn’t matter as long as the ids are unique.

Now we need to update our get_task function to use these identifiers:

def get_task(task_dict):
    """ Returns a single task layout """
    text = task_dict["content"]
    checked = task_dict["checked"]
    index = task_dict["index"]  # Get the index

    content = dmc.Grid(
        [
            dmc.GridCol(
                dmc.Checkbox(
                    id={"type": "task_checked", "index": index},  # Add ID
                    checked=checked,
                    mt=2
                ),
                span="content"
            ),
            dmc.GridCol(
                dmc.Text(
                    dcc.Input(
                        text,
                        id={"type": "task_content", "index": index},  # Add ID
                        className="shadow-input",
                        debounce=True,
                    )
                ),
                span="auto"
            ),
            dmc.GridCol(
                dmc.ActionIcon(
                    DashIconify(icon="tabler:x", width=20),
                    id={"type": "task_del", "index": index},  # Add ID
                    variant="transparent",
                    color="gray",
                    className="task-del-button"
                ),
                span="content"
            ),
        ],
        className="task-container"
    )

    return content

We now have a unique index on the three interactive components : the checkbox, the input and the delete button. Let’s write the callbacks.

2. Adding new tasks

Now we can implement the “Add Task” functionality using callbacks:

@app.callback(
    Output("main_task_container", "children", allow_duplicate=True),
    Input("new_task_button", "n_clicks"),
    State("main_task_container", "children"),
    prevent_initial_call=True,
)
def add_task(n_clicks, current_tasks):
    """ Adds a task to the list """
    if not n_clicks:
        raise PreventUpdate

    # Create new task with unique ID
    new_index = uuid.uuid4().hex
    task_dict = {
        "index": new_index,
        "content": "",
        "checked": False,
    }
    task_layout = get_task(task_dict)

    # Add new task to current tasks
    updated_tasks = current_tasks + [task_layout]
    return updated_tasks

This callback is triggered with the new_task_button is clicked. It basically takes the existing list of tasks that are in main_task_container and add a new, empty, task inside. Then it returns the new list.

We added prevent_initial_call=True to avoid running this callback when the app is loaded (the default behavior), as we know that this callback should only be triggered on a button action. It reduces unnecessary work and HTTP requests.

We also check the n_clicks is a valid positive value, in case that the callback gets triggered anyway. The raise PreventUpdate stops the callback execution.

Notice the allow_duplicate=True on the Output. It is mandatory as we will have many operations that will update the main_task_container component.

3. Removing Tasks

And finally, we implement the “Task deletion” callback following the same scheme:

@app.callback(
    Output("main_task_container", "children", allow_duplicate=True),
    Input({"type": "task_del", "index": ALL}, "n_clicks"),
    State("main_task_container", "children"),
    prevent_initial_call=True,
)
def remove_task(n_clicks, current_tasks):
    """ Remove a task from the list """
    if not any(n_clicks):
        raise PreventUpdate

    print("Entering remove_task callback")
    task_index = ctx.triggered_id["index"]

    # Get the list of existing ids.
    all_ids = [elem["id"] for elem in ctx.inputs_list[0]]

    # Find the position of element in list and remove it
    for i, task_id in enumerate(all_ids):
        if task_id["index"] == task_index:
            del current_tasks[i]
            break 

    return current_tasks

Here’s how it works:

1. When a delete button is clicked, Dash triggers this callback. We use pattern matching with {"type": "task_del", "index": ALL} to catch clicks from any delete button in our tasks. Each button has a unique index we assigned earlier.
2. The ctx.triggered_id tells us which specific delete button was clicked – specifically its index. This works because when the callback fires, Dash knows exactly which component triggered it.
3. To find and remove the correct task, we need to:
   • Get all delete button IDs using ctx.inputs_list[0] which contains the IDs of all components matching our pattern
   • Map this to just get the ID dictionaries (each with a “type” and “index”)
   • Find the position (index) in our task list that matches the triggered button’s index
   • Delete that task from current_tasks using del

As seen previously, the prevent_initial_call=True and if not any(n_clicks) check ensure we don’t accidentally delete tasks when the app first loads or if the callback is triggered without a click.

4. Run the app

Let’s run again the code. We preferably place our callbacks before the app.run_server statement:

import uuid
import dash_mantine_components as dmc
from dash import Dash, _dash_renderer, dcc, ctx, Input, Output, State, ALL
from dash.exceptions import PreventUpdate
from dash_iconify import DashIconify
_dash_renderer._set_react_version("18.2.0")  # for mantine

# sample_list_data = ...

## Layout functions:
# get_task()
# get_tasks_layout()
# get_list_layout

app = Dash(__name__)

# app.layout = ..

## Callbacks
# add_task()
# remove_task()

# Start the server
if __name__ == '__main__':
    app.run_server(debug=True)

Try to add a task, modify and delete a task in the app below:

See the full code on Github or open the app.

You can also download the full project below:

You now have a fully working —yet basic— todo app. Congratulations!

Conclusion

Let’s recap what we covered in this article:

• An introduction to DMC (Dash Mantine Components) and its components
• How to use pattern matching callbacks for dynamic interactions
• How to use CSS styling in a Dash context

In the next part, we will see how to adapt this code to handle multiple lists and keep the tasks saved after page reloads (persistence): How to build a To-Do app, part 2.

I hope you enjoyed this first part of the tutorial!

If you have any question, please join us on the dedicated topic on Plotly’s forum: here. Get notified of a new article by subscribing to the newsletter.

L’article Build a To-Do app in Python with Dash (part 1/3) est apparu en premier sur dash-resources.com.