It’s the natural continuation of the previous tutorial: How to secure a Dash app with dash-auth, where you can learn how to use dash-auth, connect to a database, and display the username.

Let’s go!

Dash-auth

If you haven’t yet, install dash and dash-auth:

pip install dash dash-auth

Then, create three files and one folder:

• app.py: the main app file
• pages/public.py: the publicly accessible page at URL “/”
• pages/private.py: the private page at URL “/private”

app.py

This file will be very similar to what we had in the previous tutorial. The list of users is hardcoded at the beginning of the file:

from dash import Dash, html, dcc, page_container
import dash_auth

# Note: better store the list in a secrets file or in a database.
USERS = {
    "alice": "secret123",
    "bob": "pa$$w0rd"
}

# Create the Dash app
app = Dash(
    __name__,
    use_pages=True,
    suppress_callback_exceptions=True
)

# Add authentication
auth = dash_auth.BasicAuth(
    app,
    username_password_list=USERS,
    secret_key="something_like_nUGz8DZvb...",
    # Public routes are not protected by authentication.
    # All others are protected by default
    public_routes=["/"]
)

# Define the layout
app.layout = html.Div([
    html.H1("My app"),
    html.P(dcc.Link("Public page", href="/")),
    html.P(dcc.Link("Private page", href="/private")),
    html.Hr(),
    page_container
])

if __name__ == '__main__':
    app.run(debug=True)

There are two key differences:

• We use pages for the Dash app (use_pages=True and suppress_callback_exceptions=True)
• We define the public pages in Dash-auth using public_routes.

Then, the layout shows two links to the two pages and the page content (using page_container).

pages/public.py

The public page will contain a button that increments itself when clicked:

from dash import html, dcc, register_page, callback, Output, Input
from dash_auth import public_callback

# The public page is the home
register_page(
    __name__,
    "/",
)

# The page layout
def layout():
    return html.Div([
        html.P("This is a public page."),
        html.Button("Click me (0)", id="button", n_clicks=0)
    ])

# A simple public callback
@public_callback(
    Output("button", "children"),
    Input("button", "n_clicks"),
)
def update_button(n_clicks):
    return f"Click me ({n_clicks})"

The only key change here is the use of public_callback (from dash-auth) instead of callback.

By default, all callbacks use the same URL endpoint: /dash-update-component. This is why we need to specify that this callback is public, while others are protected by default as soon as we add dash-auth to the app.

Under the hood, the callback ID is simply added to a list of whitelisted callbacks in the Flask server’s config.

pages/private.py

The private page will only show the username using a layout function:

from dash import html, register_page
import flask

register_page(
    __name__,
    "/private",
)

def layout():
    username = flask.session.get("user").get("email")

    return html.Div([
        html.P("If you see this, you are authenticated "),
        html.P(f"You are logged in as {username}.")
    ])

dash-auth saves the current username in a flask cookie, so we can get easily get it in the layout function, or within a callback.

Result

Now let’s run this app!
Here is a little video of what it looks like:

 Note that once we’re logged in, we can’t log out manually. The browser must be closed instead.

Conclusion

I hope this tutorial was instructive! I found it interesting that dash-auth evolved to secure multi-page apps as well, which I didn’t know until writing these two tutorials

As with the previous tutorial, the conclusion is similar: dash-auth has its drawbacks, but it’s a fairly easy solution to add an authentication layer to a dashboard or a data app. However, I would not recommend using it for production apps that have very sensitive data.

If you need proper login/logout behavior (e.g., session expiration, multiple users switching), you’ll need a more advanced system such as:

• flask_login
• OAuth (Google, GitHub…)
• Enterprise identity providers (Okta, Auth0, Azure AD…)
• Dash-Enterprise (handles LDAP, SAML, OIDC)

Happy Dash coding!

L’article How to secure a multi-page Dash app with dash-auth est apparu en premier sur dash-resources.com.

We’ll cover how to set up basic authentication, how to define a custom authentication function, and even how to connect it to a database.

Let’s go!

Basic Dash auth

First, install Dash and Dash Auth:

pip install dash dash-auth

Next, define a list of users and their associated passwords:

from dash import Dash, html
import dash_auth

#  Defining passwords directly in code is a bad practice.
# Better: store them in a secrets file or a database.
USERS = {
    "alice": "secret123",
    "bob": "pa$$w0rd"
}

# Create the Dash app
app = Dash(__name__)

# Add authentication
auth = dash_auth.BasicAuth(
    app,
    username_password_list=USERS,
    # Set the secret key to something random.
    secret_key="something_like_nUGz8DZvb..."
)

# Define the layout
app.layout = html.Div([
    html.H1("Protected app"),
    html.P("If you see this, you are authenticated ")
])

if __name__ == '__main__':
    app.run(debug=True)

The secret key must be unique and… secret .
To generate one, run this in your terminal:

python -c "import secrets; print(secrets.token_urlsafe(32))"

Note: the secret_key isn’t mandatory for dash-auth since it doesn’t use cookies. However, adding it removes the warning: “WARNING:root:Session is not available. Have you set a secret key?”.

Then, just run your app with python app.py. You should get this result:

And after log-in:

That’s it! You get a protected page.

There are some limitations:

• You cannot customize the login/password popup window, it’s natively handled by the browser.
• Users cannot logout: the session is active until they close their browser.
• The list of users is fixed: you will need to reload the app to add or remove a user or update a password.

Retrieve the user

The user information is stored in the flask.session object. It’s therefore easy to retrieve it in a callback:

# ...

# Define the layout
app.layout = html.Div([
    html.H1("Protected app"),
    html.P("If you see this, you are authenticated "),
    html.P(id="user_info")  # added this
])

# Define the callback
@app.callback(
    Output("user_info", "children"),
    Input("user_info", "id"),  # dummy trigger
)
def update_user_info(_):
    """ Display the username of the logged in user. """
    username = flask.session.get("user").get("email")
    return f"You are logged in as {username}."

if __name__ == '__main__':
    app.run(debug=True)

Let’s explain this code:

• I added a new paragraph #user_info
• A new callback is triggered at initialization time. It displays the username.

Now let’s see the result:

Authentication function

It’s possible to use an arbitrary python function to handle authentication. This is useful to:

• store and compare hashed passwords instead of plain passwords;
• retrieve user information and passwords from a database.

Comparing hashed passwords

Storing passwords in clear in the code is a pretty bad practice for security and confidentiality reasons. Instead, a better practice is to store hashed passwords instead of the clear version. If the password leaks, the original password can’t be found!

You can hash a password using the generate_password_hash from werkzeug.security package. For instance:

from werkzeug.security import generate_password_hash
print(generate_password_hash("secret123"))
# scrypt:32768:8:1$PICpPDH9JdIz75DT$d5f81a560015a407e51989f03d046816954ba2b8d5ee520b999f492352b9e8a39084210ea2fe3bfdcdc2a94047a5397e04bbf3663b505967d3d1ea91a95101d7'

Then, we can compare the two password hashes with the check_password_hash function:

from werkzeug.security import check_password_hash

def auth_func(username, password):
    """ Authenticate the user using hashed passwords. """

    # Check the user exists and the password is correct
    if username in USERS and check_password_hash(USERS[username], password):
        return True
    return False

That’s it. We just check the user exists, and compare its hash.

Let’s put this all together and replace the USERS list with the auth_func parameter:

from dash import Dash, html
from dash_auth import BasicAuth
from werkzeug.security import generate_password_hash, check_password_hash

# This time, we store hashed passwords. 
# Meaning that they can't be compromised if our code leaks.
USERS = {
    "alice": "scrypt:32768:8:1$HtB7iBw3ZGspBOHX$36879fd912db96322af2c33c3eb3fd0142ca2ec51988f332cc477b89c012449e5562487b410264b02d495d785780d0099e9130b42c4f61d7bc9166b93f7d1626",
    "bob": "scrypt:32768:8:1$j2rFpuXSr2D5t4Ij$9436a942b25f93054d3c96e54dcdd342c97f86515e09aafecd564984c22beb991029b70a89164215590ec131be4e13a12e043f4572ceb06576f86f925b1b9d65"
}

def auth_func(username, password):
    """ Authenticate the user using hashed passwords. """
    if username in USERS and check_password_hash(USERS[username], password):
        return True
    return False

app = Dash(__name__)
auth = BasicAuth(
    app, 
    auth_func=auth_func, # We now use auth_func in place of the user list.
    secret_key="something_like_nUGz8DZvb..."
)

app.layout = html.Div([
    html.H1("Protected app"),
    html.P("If you see this, you are authenticated.")
])

if __name__ == "__main__":
    app.run(debug=True)

The result is visually the same for the user, but now passwords are not stored in clear. It also means that the original passwords are not shared with the developers having access to the Dash app code.

Much better!

Use a database

We can also use the authentication function to request an external database. The good thing with this solution is that the list of users can be dynamically managed.

Let’s create a simple script to initialize a sqlite database:

# init_db.py
import sqlite3
from werkzeug.security import generate_password_hash

DB_PATH = "users.db"

def init_db():
    """Create a tiny users table and seed two demo users if empty."""
    with sqlite3.connect(DB_PATH) as con:
        cur = con.cursor()
        cur.execute("""
            DROP TABLE IF EXISTS users;
            CREATE TABLE users (
                username TEXT PRIMARY KEY,
                password_hash TEXT NOT NULL,
                language TEXT NOT NULL
            )
        """)

        # Insert values
        cur.executemany(
            "INSERT INTO users(username, password_hash, language) VALUES (?, ?, ?)",
            [
                ("alice", generate_password_hash("secret123"), "en"),
                ("bob",   generate_password_hash("pa$$w0rd"), "fr"),
            ],
        )

if __name__ == "__main__":
    init_db()
    print("Database initialized")

Note that we directly save the hashed password in the users table.

Then, we simply query this database in our auth_func function to get the hashed password of a user, then compare it:

from dash import Dash, html
from dash_auth import BasicAuth
from werkzeug.security import generate_password_hash, check_password_hash
import sqlite3

DB_PATH = "users.db"

def get_hash(username):
    """Fetch the stored hash for a username, or None."""
    with sqlite3.connect(DB_PATH) as con:
        cur = con.cursor()
        cur.execute("SELECT password_hash FROM users WHERE username = ?", (username,))
        row = cur.fetchone()
        return row[0] if row else None

def auth_func(username, password):
    """ Authenticate the user using hashed passwords. """
    hash_from_db = get_hash(username)

    if hash_from_db and check_password_hash(hash_from_db, password):
        return True
    return False

app = Dash(__name__)
auth = BasicAuth(
    app, 
    auth_func=auth_func,
    secret_key="something_like_nUGz8DZvb..."
)

app.layout = html.Div([
    html.H1("Protected app"),
    html.P("If you see this, you are authenticated "),
])

if __name__ == "__main__":
    app.run(debug=True)

That’s it!

Now you can modify the list of users, modify passwords, etc. in the database without having to reload the application.

It doesn’t need to be a sqlite database. You can also make HTTP requests to a database provider, or query any other type of database (Postgresql, MongoDB, …).

Keep in mind that the auth_func function is executed for every callback and every dash request. If the check takes too much time, think about caching solutions like memoize.

Why you can’t logout

dash-auth uses HTTP Basic Authentication, which is built into your browser.

• Your credentials (username + password) are cached.
• The browser automatically re-sends them with every request.
• There’s no “logout” button because the browser doesn’t expose a way to clear those credentials.

The only way to log out? Close the browser tab or window.

Conclusion

This tutorial helped you to secure a Dash app using the dash_auth package.

dash-auth has its drawbacks, but it’s a fairly easy solution to add an authentication layer to a dashboard or a data app. However, I would not recommend using it for production apps that have very sensitive data.

If you need proper login/logout behavior (e.g., session expiration, multiple users switching), you’ll need a more advanced system such as:

• flask_login
• OAuth (Google, GitHub…)
• Enterprise identity providers (Okta, Auth0, Azure AD, …)
• Dash-Enterprise (handles LDAP, SAML, OIDC)

In the next tutorial, we will see how to use dash-auth for multi-pages Dash apps.

I hope to see you there!

L’article How to secure a Dash app with dash-auth est apparu en premier sur dash-resources.com.

In this new article, I want to soften my original take and explain when to use allow_duplicate=True and when not to use it with clear examples. Of course, everything you’ll read here is based on my personal experience and might not cover all use cases!

Let’s dive in!

First, what is allow_duplicate=True?

In Dash, each Output is typically tied to exactly one callback. Attempting to attach an additional callback to the same Output will normally raise an error:

However, since version 2.9 Dash provides an advanced setting—allow_duplicate=True—that lets you break that convention. This flag, placed in the Output declaration, tells Dash that you intend to create another callback targeting the same Output that was already used in a different callback.

Here is an example:

# First callback
@app.callback(
    Output('output', 'children', allow_duplicate=True),
    Input('input-1', 'value'),
    prevent_initial_call=True,
)
def update_output_1(value):
    # ... some processing 
    return value

# Second callback (duplicate output)
@app.callback(
    Output('output', 'children'),
    Input('input-2', 'value'),
    prevent_initial_call=True,
)
def update_output_2(value):
    # ... some other processing
    return value

Here, both callbacks target the same Output component property. Because the first callback has allow_duplicate=True, the second is allowed to share that same Output. We could just as easily add a third one, or even more.

Note that the allow_duplicate=True is required only for the first callback. But if you change the order callbacks are written in the code, you’ll need to update it. Setting it everywhere makes it less error-prone.

Using this option will also requires setting prevent_initial_call=True to ensures the callbacks don’t get triggered simultaneously (which is what we want to avoid, as you’ll read later).

Pros and cons of allow_duplicate=True

Don’t get me wrong, allow_duplicate=True is useful.

Sometimes we have two distinct user interactions that need to update the same component. As the number of inputs grows, we quickly end up modifying a complex login into a “mega-callback”. It therefore become a nightmare to maintain and little changes can break many behaviors.

Instead, allow_duplicate=True enables splitting the responsibilities into smaller, clearer, more isolated callbacks.

But this goes against the first principle: having only one output per callback, which is generally a good design principle. Not following it has potential drawbacks and trade-offs to consider .

Harder to track logic & Maintainability Concerns

Normally in Dash, each property is updated by exactly one callback, so you can always look at that callback to know “what logic is behind this value.” Breaking that rule can lead to confusion: “Wait, which callback is controlling the output now? Or is it both?”

Multiple callbacks returning to the same output can significantly complicate debugging and future maintenance. Other developers (or a future you) might have difficulty quickly discerning how that one visible component is being updated in different contexts.

Potential race conditions

If you have multiple callbacks writing to the same component property at roughly the same time, you may get race conditions—where whichever finishes last overwrites the other. This can cause flickering, inconsistent states, or unexpected behavior if not carefully managed.

This is something that I saw happening and I wrote an article about it in detail here: The dark side of allow_duplicates & making calbacks sequential.

Good use example 1: separate concern

Let’s take an example of fully separated logic.

The following is a true example of a login/register process that I experienced in my app:

@callback(
    Output("session_id", "data", allow_duplicate=True),
    [
        Input("login_button", "n_clicks"),
        State("login_email", "value"),
        State("login_password", "value"),
    ],
    prevent_initial_call=True,
)
def user_identification(button_n_clicks, username, password):
    """This callback handles the login of a user given a username and password """
    # ... handle login
    session_id = uuid.uuid4()
    return session_id

@callback(
    Output("session_id", "data", allow_duplicate=True),
    [
        Input("register_button", "n_clicks"),
        State("register_email", "value"),
        State("register_password", "value"),
        State("register_lastname", "value"),
        State("register_firstname", "value"),
        State("register_company", "value"),
        State("register_tel", "value"),
    ],
    prevent_initial_call=True,
)
def user_registration(button_n_clicks, email, password, lastname, firstname, company, telephone):
    """This callback handles the registration of a new user"""
    # ... handle registration
    session_id = uuid.uuid4()
    return session_id

Both callbacks handle multiple inputs (email, password, firstname, lastname, etc.) and they return a session_id, that is stored in a session dcc.Store.

This session_id will then trigger another set of callbacks that are related to the loading of an user: displaying its name, loading its preferences, etc.

What’s interesting about this example is that it actually benefited from using allow_duplicate. The two callbacks are different and process a different set of inputs, thus, it makes sense to have two separate callbacks.

This is what it looked like if merged into one large callback:

@callback(
    Output("session_id", "data"),
    [
        Input("login_button", "n_clicks"),
        Input("register_button", "n_clicks"),
    ],
    [
        State("login_email", "value"),
        State("login_password", "value"),
        State("register_email", "value"),
        State("register_password", "value"),
        State("register_lastname", "value"),
        State("register_firstname", "value"),
        State("register_company", "value"),
        State("register_tel", "value"),
    ],
    prevent_initial_call=True,
)
def user_identification_or_registration(login_n_clicks, register_n_clicks, username, password1, email, password2, lastname, firstname, company, telephone):
    """This callback handle the login of a user given a username and password """
    if ctx.triggered_id == "login_button":
        # ... handle login
        session_id = uuid.uuid4()
        return session_id
    elif ctx.triggered_id == "register_button":
        # ... handle registration
        session_id = uuid.uuid4()
        return session_id

But large callbacks also have their own drawbacks: harder to maintain, multiple inputs to handle, etc… Plus, we would be sending unnecessary information with every callback trigger—making it less efficient

In this case, allow_duplicate proves really helpful in reducing the complexity and making a more readable and maintainable code.

Prior the introduction of allow_duplicate, I actually handled this with two dcc.Store : session_id_login and session_id_register, which were both triggering a callback updating a single output: session_id. They were used as temporary storage —but that was less efficient and required one round trip to the server as well as one unecessary callback execution.

Good use example 2: partial update

The previous example illustrated how allow_duplicate can help separate callbacks when logic is different. It’s more about callback designing, but there are solutions to do it without allow_duplicate.

The following example could not be possible without the help of allow_duplicate .

Imagine you have a figure. And you want to update only the title of a figure without redrawing the whole figure. The code would look like:

@callback(
    Output('graph', 'figure', allow_duplicate=True),
    Input('dropdown', 'value'),
    prevent_initial_call=True,
)
def update_graph(value):
    # Download very large data from a server
    df = pd.read_csv('https://.../data.csv')
    fig = px.line(df, x='date', y='value', color='category')
    return fig

@callback(
    Output('graph', 'figure'),
    Input('title_input', 'value'),
    prevent_initial_call=True,
)
def update_title(title):
    # Just modify the title with Patch()
    fig = Patch()
    fig['layout']['title'] = title
    return fig

In update_graph, we load a large dataset and return a figure. In the other callback update_title, we only update the title of the figure and return it, using Patch().

What’s wonderful here is that the use of allow_duplicate and Patch() conjointly helped updating the figure without the need to reload the whole data and create the entire figure again.

It’s a more efficient solution, that would translate in a more responsive application and a better user experience.

Lean more about partial updates here: https://dash.plotly.com/partial-properties

In this case, allow_duplicate enabled something that wasn’t possible before.

Bad use example 1: harder to track

The following is a fictitious bad example, and/or bad callback design, where two callbacks update the same container:

@callback(
    Output("results_container", "children", allow_duplicate=True),
    Input("search_button", "n_clicks"),
    prevent_initial_call=True,
)
def search_results(n_clicks):
    """This callback searches for results when the search button is clicked"""
    if n_clicks is None:
        raise PreventUpdate
    
    # some processing
    
    return [
        html.Div("Search results from button click"),
        html.Div([html.Span(f"Result {i}") for i in range(5)])
    ]

@callback(
    Output("results_container", "children", allow_duplicate=True),
    Input("filter_dropdown", "value"),
    prevent_initial_call=True,
)
def filter_results(filter_value):
    """This callback filters results when dropdown value changes"""
    if filter_value is None:
        raise PreventUpdate
    
    # some processing
    
    return [
        html.Div(f"Filtered results for: {filter_value}"),
        html.Div([html.Span(f"Filtered item {i}") for i in range(3)])
    ]

Both search_results and filter_results can be triggered . If both are triggered at the same time, we will have either one result or the other (the last callback being executed), which is misleading.

The issue here is that we’re using one single container, result_container, to display two different solution. And allow_duplicate=True made it possible.

To be clear, the above code will work. It’s just that in my opinion, this is not a good use of allow_duplicates for the sake of maintainability and callback logic.

Instead, it would have been better to just have two separate containers (e.g. a new search_result_container and filter_result_container) or to merge the logic into one callback.

Bad example 2: race condition

This example will illustrate the race condition problem.

Imagine you need to store the number of clicks on two buttons in a list. The first button increments the first count, and the second button updates the second count:

# Our dcc store is like this:
results_store = [0, 0]

@callback(
    Output("results_store", "data", allow_duplicate=True),
    Input("button1", "n_clicks"),
    State("results_store", "data"),
    prevent_initial_call=True,
)
def update_store_from_button1(n_clicks, current_data):
    """ Store the number of clicks on button1"""
    # Sleep randomly to simulate network latency
    time.sleep(random.uniform(0.5, 2))

		# Update button 1 count
    current_data[0] = n_clicks
    return current_data

@callback(
    Output("results_store", "data", allow_duplicate=True),
    Input("button2", "n_clicks"),
    State("results_store", "data"),
    prevent_initial_call=True,
)
def update_store_from_button2(n_clicks, current_data):
    """ Store the number of clicks on button2"""
    # Sleep randomly to simulate network latency
    time.sleep(random.uniform(0.5, 2))
    
    # Update button 2 count
    current_data[1] = n_clicks
    return current_data

Each callback is triggered by its button, uses the state of current_data and returns the updated value.

Let’s give an example:

• click on button1 → … add one to the number of clicks (current data state is [0, 0]) … → the callback returns [1, 0]
• then click on button2 → … add one to the number of clicks (current data state is [1, 0]) … → the callback returns [1, 1]

This is all good because we click and wait for the callback to be fully executed. Now, what if we click to both buttons at the same time ?

• click on button1 → … add one to the number of clicks (current data state is [1, 1]) … → the callback returns [2, 1]
• click on button2 → … add one to the number of clicks (current data state is [1, 1]) … → the callback returns [1, 2]

Depending on which callback finishes first, we’ll get different results: [2, 1] or [1, 2].

You can try a live demo below (or click here):

In this example, I chose to simulate network latency with time.sleep() so that the problem is emphasized. When testing locally, you might not notice the problem—but it can become obvious once deployed to production.

In this case, a better solution would have been to

• use Patch() to be sure we do not rely on states
• use different dcc.Store to store the two information.

I hope this example helped to understand race conditions. Again, this other article also illustrates this problem.

Conclusion

I hope this article helped you to understand what are the good and bad practices with this powerful option, allow_duplicate.

If you’re unsure when to use it, here are a few rules I’ve come up with:

I you have questions or want to join the discussion, I created at topic here: plotly forum.

— Happy coding!

L’article How to use allow_duplicate (good and bad practices) est apparu en premier sur dash-resources.com.

Ensuring that some information is stored without desynchronization issues with callbacks is also a problem that I encountered a few times when developing Dash applications. As a result, I want to discuss here a few solutions and when to approach them.

Let’s dive in

The problem

Imagine you have a dcc.Store("user_data") that stores something like {"firstname": "John", "lastname": "Doe", "age": 50, ...}. This Store is set via multiple inputs: first_name, last_name, age, …It is a large dictionary and you might have multiple callbacks updating it.

To update this user_data from many inputs, you can set allow_duplicate=True. That way, you are not restricted to only one callback for this output. You just need to get the full user_data back each time (as a State), modify it, and return it.

The code would be something like:

@callback(
    Output("user_data", "data", allow_duplicate=True),
    Input("first_name", "value"),
    State("user_data", "data"),
    prevent_initial_call=True,
)
def update_first_name(first_name, user_data):

    # Just update user_data with the first name
    if first_name: 
        user_data["first_name"] = first_name
        return user_data

    raise PreventUpdate

@callback(
    Output("user_data", "data", allow_duplicate=True),
    Input("last_name", "value"),
    State("user_data", "data"),
    prevent_initial_call=True,
)
def update_last_name(last_name, user_data):

    # Just update user_data with the last name
    if last_name: 
        user_data["last_name"] = last_name
        return user_data

    raise PreventUpdate

# ... other callbacks

For the moment, everything is fine. But a problem starts appearing if you trigger all inputs at the same time, e.g. to set initial values:

# A callback to simulate the desynchro problem.
# As it triggers the first name and last name input as the same time
@app.callback(
    Output("first_name", "value"),
    Output("last_name", "value"),
    Input("load_data", "n_clicks"),
)
def load_data(n_clicks):
    if n_clicks:
        return "Mickael", "Jackson"
    raise PreventUpdate

A de-synchronization problem appears, between the inputs and the result in the user_dict memory store. The inputs have the updated values, not the stored memory user_dict.

You can try it below (or click here):

• if you enter “john” and “doe”, then everything gets updated correctly.
• then click on “load” data. the user_data should contains firstname = “mickael” and lastname = “jackson”, but instead some discrepency appears.

Why this problem appears.

Both callbacks are run at the same time. If update_first_name is triggered at the same time update_last_name is triggered, the state value of user_data do not contains the updated first name. It also works the way around, which explains that sometimes we don’t have the first name, and sometimes the last name. it depends which callback is fired first.

And having Input("user_data", "value") instead of State("user_data", "value") might be possible in some cases, but you would end up with some weird behavior due to the circular pattern. If you have 5 or 10 callbacks following the same scheme, your app will basically blow up because of all the callbacks triggered in all directions.

Here is a video example with 4 inputs:

Notice how many callbacks are triggered with a single change in one input (1 HTTP request = 1 callback)! Because of the circular scheme, callbacks get triggered unecessarily.

The solution can be to ensure that callbacks are executed sequentially: first update_first_name, and then update_last_name, with the updated value of user_data. That’s actually what it “seems to be”, but the real solution is to think about the problem differently.

But let’s see why.

Solution 1: chaining callbacks

How do we make callbacks sequential?

Chaining is the simplest form of sequential callbacks. In that case, you just need to connect one of the outputs of the first callback as an input for the second callback (A -> o -> B -> o).

But as I said previously, we cannot set user_data as an input for the second callback (because of circular dependencies).

Instead, we can use an intermediary dcc.Store, that will just be used as a trigger. I think a timestamp is a good fit for this purpose:

@callback(
    Output("user_data", "data", allow_duplicate=True),
    Output("intermediary_timestamp", "data"),
    Input("first_name", "value"),
    State("user_data", "data"),
    prevent_initial_call=True,
)
def update_first_name(first_name, user_data):

    # Just update user_data with the first name
    if first_name: 
        user_data["first_name"] = first_name
        return user_data, time.time()

    raise PreventUpdate

@callback(
    Output("user_data", "data", allow_duplicate=True),
    Input("last_name", "value"),
    Input("intermediary_timestamp", "data"),
    State("user_data", "data"),
    prevent_initial_call=True,
)
def update_last_name(last_name, timestamp, user_data):

    # Just update user_data with the last name
    if last_name: 
        user_data["last_name"] = last_name
        return user_data

    raise PreventUpdate

In this example, the update_first_name callback will return the user_data and a timestamp. The dash-renderer will know that it has to wait before triggering update_last_name because intermediary_timestamp must be ready before executing it.

Pro-tip: we could have used the property modified_timestamp of our user_data dcc.Store component as an input. i.e., replacing Input("intermediary_timestamp", "data") by Input("user_data", "modified_timestamp"). That works too and we don’t even need the intermediary dcc.Store

Solution 2: rewriting callbacks

But wait wait wait… Should we really need to chain callbacks?
Often the best option is to handle the processing of the two callbacks inside the same callback.

@callback(
    Output("user_data", "data"),
    Input("first_name", "value"),
    Input("last_name", "value"),
    # .. other possible inputs
    State("user_data", "data"),
)
def update_user_data(first_name, user_data):

    # Just update user_data with the first name
    if first_name: 
        user_data["first_name"] = first_name
    if last_name:
        user_data["last_name"] = last_name
    # .. other possible values

    return user_data

And that solves the synchronization problem.

However, it can happen that you don’t want to get the value from the input if it wasn’t really triggered.

Hopefully, there is a way to filter which input was really triggered, using ctx.triggered_prop_ids (documentation link). Let’s see an example:

def slow_processing(user_data):
    # Simulate some long processing, e.g. requesting a database
    time.sleep(4)
    return "Some information"


@callback(
    Output("user_data", "data"),
    Input("first_name", "value"),
    Input("last_name", "value"),
    Input("info_button", "n_clicks"),
    # .. other possible inputs
    State("user_data", "data"),
)
def update_user_data(first_name, last_name, n_clicks, user_data):

    # Identify which inputs were triggered
    first_name_triggered = "first_name" in ctx.triggered_prop_ids.values()
    last_name_triggered = "last_name" in ctx.triggered_prop_ids.values()
    button_triggered = "info_button" in ctx.triggered_prop_ids.values()

    # Update user_data accordingly
    if first_name_triggered and first_name: 
        user_data["first_name"] = first_name
    if last_name_triggered and last_name:
        user_data["last_name"] = last_name

    if button_triggered and n_clicks:
        # An information that takes time to retrieve
        # You want to compute it only if button was *really* triggered
        info = slow_processing(user_data)  
        user_data["info"] = info

    # .. other possible inputs being hanled

    return user_data

The good thing is that this solution is scalable: we can continue adding inputs and keys to our user_data easily. And we get rid of allow_duplicate=True which is useful but also leads to “callback bad design”. I’ll come back to this later.

Solution 3: using intermediary stores

Part of the problem that we have here is the use of one memory store for multiple information.

So instead of trying to store everything inside the same callback, we could actually split the user_data dict into as many stores as required: user_first_name, user_last_name, user_age, user_info, etc.

Then, we would have to merge all this information into one callback:

app.layout = [
    # ...
    dcc.Store(id="user_first_name"),
    dcc.Store(id="user_last_name"),
    dcc.Store(id="user_age"),
    dcc.Store(id="user_info"),
    # ... other values
]

@callback(
    Output("user_first_name", "data"),
    Input("first_name", "value")
)
def update_first_name(first_name):
    if first_name: 
        return first_name
    raise PreventUpdate

@callback(
    Output("user_last_name", "data"),
    Input("last_name", "value")
)
def update_last_name(last_name):
    if last_name: 
        return last_name
    raise PreventUpdate

@callback(
    Output("user_age", "data"),
    Input("age", "value")
)
def update_age(age):
    if age: 
        return age
    raise PreventUpdate

@callback(
    Output("user_info", "data"),
    Input("info_button", "n_clicks"),
    State("user_data", "data")
)
def update_info(n_clicks, user_data):
    if n_clicks:
        info = slow_processing(user_data) 
        return info
    raise PreventUpdate

# ... other callbacks 

# then we update the user_data:
@callback(
    Output("user_data", "data"),
    Input("user_first_name", "data"),
    Input("user_last_name", "data"),
    Input("user_age", "data"),
    Input("user_info", "data"),
    prevent_initial_call=True,
)
def update_user_data(first_name, last_name, age, info):
    return {
        "first_name": first_name,
        "last_name": last_name,
        "age": age,
        "info": info,
        # ... other properties and values?
    }

If all callbacks are triggered at the same time, update_user_data will be the last one triggered, and all input values will be filled before it can run. That’s a good way to make callbacks sequential.

The good thing about this solution is that we can get rid of allow_duplicate=True too. The bad thing is that it is poorly scalable: we would need to add as many stores and callbacks as we have keys to update in user_data.

As you can see, the initial problem was made possible because of allow_duplicate=True. If it wasn’t an option, we might have used this solution in the first place. And even if it’s a verbose solution, it’s a good simple solution. allow_duplicate=True is a fortunate option to use in some cases, but it often leads to bad callback design.

Pro-tip: 99% of the time you don’t need allow_duplicate=True. Try to avoid it as much as possible. It can creates callback mess.

Solution 4: using Partial Update

The above solutions will rely on the fact that we get user_data as a State.
But what if user_data is very large? Dash callbacks are HTTP requests, so a large input or state would result in a large HTTP request. Depending on the user’s bandwidth, it can take time.

Instead, we could use Patch() (documentation link) to only update one key at a time, not the whole user_data dictionary.

Let’s see the code:

from dash import Patch

@callback(
    Output("user_data", "data", allow_duplicate=True),
    Input("first_name", "value"),
    prevent_initial_call=True,
)
def update_first_name(first_name):

    # Just update user_data with the first name
    if first_name: 
        user_data = Patch()
        user_data["first_name"] = first_name
        return user_data

    raise PreventUpdate

@callback(
    Output("user_data", "data", allow_duplicate=True),
    Input("last_name", "value"),
    prevent_initial_call=True,
)
def update_last_name(last_name):

    # Just update user_data with the last name
    if last_name: 
        user_data = Patch()
        user_data["last_name"] = last_name
        return user_data

    raise PreventUpdate

And that’s it. :-). So, how does it works ?

• In the other solutions, Dash will send the whole user_data to be modified in a callback, gets the new full value, and updates in its storage.
• With Patch(), Dash will just send the input and get just the piece of information that was modified. It then updates the full object in its storage with the new piece of information.
• Unless two callbacks modifies the same piece of information (come’on, you want problems), this solution do not require sequential execution.

It’s maybe the most powerful solution, especially if user_data is very large. It can work with solution n°1, n°2 and n°3. We still use allow_duplicate, but it is not a problem anymore.

Conclusion

So what’s the best solution? As always, it depends on your use case.

But here key takeaways:

• If you can, try to avoid using allow_duplicate=True and have one callback update one output
• If you can, try to merge multiple callbacks into one callback. It’s more efficient, and you will de-facto solve the synchronization problem
• If you have large data, Patch() is probably the best solution.

I hope this article helped you learn about different approaches and how things can get complex with Dash callbacks. Feel free to ask questions or join the discussion here.

Happy coding!

L’article The dark side of allow_duplicate & making callbacks sequential est apparu en premier sur dash-resources.com.

In this tutorial, we’ll explore what dcc.Store is, how it works, and best practices for using it effectively in Dash applications.

Level up your Dash skills! I wrote a full course to help you learn how to think and design a Dash app with simple and advanced callbacks. Real pro-tips, from a real human expert!

What is dcc.Store, and why do we need it?

A bit of history

Initially, people used to store data for Dash apps in hidden HTML components. However, that wasn’t an ideal solution: there was no way to retain data after reloading the page or closing the tab, and embedding large amounts of data in HTML could bloat the app and cause serious slowdowns.

As a result, the Plotly team introduced dcc.Store in Dash 0.32, and it has become one of the most essential components.

Introduction to dcc.Store

The dcc.Store component serves multiple important functions: it enables data sharing between callbacks without repeatedly passing large objects, stores intermediate calculation results to prevent costly recomputations, and can maintain data persistence during page reloads or multi-page navigation—when configured with the appropriate storage type.

It has four key properties:

• id: Like any other regular Dash component, this is used for callbacks.
• storage_type: Either memory, session, or local (more on this below).
• data: The initial value for the store when the app loads.
• modified_timestamp: The latest modification timestamp.

You can create as many dcc.Store components as you need and include them in your app’s layout. Here’s an example:

from dash import Dash, dcc, html, Input, Output, State

app = Dash(__name__)

app.layout = html.Div([
    html.H1("My app"),
    # ... other components

    # Memory stores examples
    dcc.Store("user_id_store", storage_type="memory"),
    dcc.Store("dashboard_option_store", storage_type="local", data=False),
])

# A callback example 
@app.callback(
    Output("user_id_store", "data"),
    Input("button_login", "n_clicks"),
)
def login_callback(n_clicks):
    if n_clicks:
        # ... get user_id from login form
        return user_id
        
# Another callback example with user_id as state
@app.callback(
    Output("dashboard_option_store", "data"),
    Input("dashboard_option_dropdown", "value"),
    State("user_id_store", "data"),
)
def dashboard_option_callback(dashboard_option, user_id):
    if user_id:
        # ... get dashboard option for this specific user_id
        return dashboard_option

In this example, we set up a user_id_store component to keep the current user ID. That information can then be passed as state to many callbacks requiring knowledge of which user is performing a particular action, such as selecting a dashboard option.

Why it is needed

Dash operates as a stateless framework, meaning each callback function operates independently—processing requests and discarding user-specific data afterward. This architecture makes global variables ineffective for data persistence across callback executions (you should never use global variables in Dash apps!).

The dcc.Store component provides client-side storage for JSON-serializable data directly in the user’s browser, making it easy to retain and share data across multiple interactions (i.e., callbacks). It is perfect for storing IDs, or small size data.

However, if you want to maintain access to larger data between interactions (i.e. callbacks), you will need alternative storage methods like an external database (Redis, SQLite, PostgreSQL, MongoDB) because stored data on the clientside would require transmitting it over the network every time, which could be a huge bottleneck.

Learn best practices for callbacks here: Dash callbacks best practices (with examples)

Understanding dcc.Store Storage Types

A key feature of dcc.Store is its flexibility in how data is stored. It offers three different storage types, each with unique characteristics:

# Three different ways to initialize a store
dcc.Store(id='memory-store', storage_type='memory')  # Default
dcc.Store(id='session-store', storage_type='session')
dcc.Store(id='local-store', storage_type='local')

Each storage type serves different purposes:

• Memory (storage_type='memory'): Data persists only for the current page session. If the user refreshes the page, the data is lost. This is the default and is best for temporary data that can be regenerated easily.
• Session (storage_type='session'): Data persists across page refreshes within the same browser tab but is cleared when that tab (or the browser) is closed. This uses the browser’s sessionStorage API.
• Local (storage_type='local'): Data persists indefinitely, even after the browser is closed and reopened. This uses the browser’s localStorage API and is great for user preferences or application settings.

Your choice depends on your specific requirements. For instance, use local for user preferences that should persist across sessions, session for data that should survive a refresh but not a browser restart, and memory for transient data like intermediate computational results.

Pro-tip: It can be helpful to add a suffix like -store or _memory to all your dcc.Store IDs. This makes it easy to identify which inputs and outputs are stores in your callbacks.

How much can you store?

The amount of data that can be stored in dcc.Store depends on the selected storage_type:

• Memory: Limited only by the browser’s available memory but cleared on page refresh.
• Session and Local: These rely on the browser’s sessionStorage and localStorage APIs, which typically allow up to 10MB per domain (source). However, this limit varies between browsers and may be smaller on mobile devices.

Additionally, performance considerations matter when using dcc.Store for large datasets. Each time a callback accesses or updates dcc.Store, Dash serializes and transmits the data over the network. If you store large JSON objects (for example, a DataFrame of thousands of rows), it can lead to significant bandwidth usage and slow performance, especially for users with limited internet speeds. In such cases, consider using server-side caching or database storage instead.

How to debug dcc.Store

Depending on the storage type, you can inspect, update, or delete storage values, which can be useful during development, especially for session and local types.

For this example, I will use a To-Do app built in Dash. You can find how I created it in this tutorial: Build a To-Do app in Python with Dash (part 2/3) and open the live app here.

1. Open your browser’s Developer Tools (press F12 or right-click on the page and select Inspect).
2. Navigate to Application (or a similar tab), where you can find Local Storage and Session Storage.

You will find the Local Storage and Session Storage list. However, store components using storage_type="memory" will not appear: the data is stored as a React state. It’s encapsulated in the JavaScript memory of the page and is not easily accessible. It’s also not particularly useful to access it directly.

When clicking, you can see the list of dcc.Store keys. Each store will have one entry for the content (JSON-serialized) and one entry for the modified_timestamp.

A few important notes:

• Confidentiality: Notice how visible the information stored in a store component is to the end user! In the example above, the entire list of tasks is clearly visible. As a result, you should always remember not to store any confidential information in a dcc.Store component. This is especially true for localStorage, which can persist indefinitely (someone accessing your Dash app months later could see the same data as another user from months prior).
• Sharing storage: localStorage and sessionStorage are shared with other libraries in your app. So if you use third-party libraries, you may see their entries here. For example, I use a chatbot in one of my apps, and this chatbot extension stores its own info in localStorage.

Pro-tip #1: When working with storage_type="local", remember to delete your local storage entries when you need to simulate a fresh app initialization.

Pro-tip #2: If you develop many apps at the same local URL (e.g., http://127.0.0.1:8050/), you can accidentally overwrite your local storage data across apps if you use the same store IDs. Keep this in mind to avoid unexpected bugs!

Some best practices for dcc.Store

Serialize data properly

A common error is attempting to store non-JSON-serializable objects, such as Pandas DataFrames, NumPy arrays, or custom Python objects. Since dcc.Store supports only JSON-compatible data, make sure to convert these objects first (using .to_json(), .tolist(), json.dumps(), etc.):

TypeError: Object of type DataFrame is not JSON serializable.

If your data is not JSON serializable, it’s a strong indication that you should rely on an external source (e.g. a database). Note that for small images, you can still encode them in base64 to get a string.

Don’t store large objects or DataFrames

Avoid storing large datasets in dcc.Store. It’s better to use an external database and only store dataset IDs in the dcc.Store component.

There’s no hard limit for maximum size -it depends on your bandwidth and dataset. However, I would recommend keeping it under 10 MB for high-speed connections, 100KB-1MB for a production ready app.

Good to know: If you want to see a practical example of the impact it can have and how to debug performance issues with network development tools, see here: Dash app callback performance: a real-world debugging example

Use the right storage type

Select storage type memory, session, or local based on how long the data should persist. If you don’t need any persistence, keep it light with memory or session. And remember that you have a limited amount of storage made possible by the browser.

Trigger callbacks efficiently

You can use the modified_timestamp property instead of data if you only need the store as a trigger (without the data itself). This reduces the data transmitted over the network. You can also use modified_timestamp to trigger a callback at initialization time.

Good to know: See an example of how you can use modified_timestamp instead of data here.

Conclusion

I hope this article was helpful. My goal was to provide complementary information to the official documentation!

dcc.Store is an essential component that simplifies state management in Dash apps. By using it, you can avoid redundant computations, maintain user session data, and enhance performance. As your app grows, choosing the right storage type and structuring your callbacks efficiently will become increasingly important.

• If you want to learn more, take a look at the To-Do app tutorial, which provides a practical example of how to use dcc.Store: Build a To-Do app in Python with Dash (part 1/3).
• If you have any questions, feel free to ask on the Plotly forum here.

Happy coding !

Level up your Dash skills! I wrote a full course to help you learn how to think and design a Dash app with simple and advanced callbacks. Real pro-tips, from a real human expert!

L’article Understanding dcc.Store in Dash Plotly est apparu en premier sur dash-resources.com.

In this blog post, I’ll walk you through how I quickly enhanced my app’s performance by analyzing Dash callback execution, which hopefully give you some ideas for your debugging too.

Context

My dash application is essentially a real estate map which displays information when clicking on map points.

The click that displayed information felt instant when running locally, but when running in production, it had about a one-second delay. I also noticed that the more elements I displayed on my map, the worse the performance became.

My production app and local app differ in some ways, and I could imagine at least two reasons:

• Maybe callbacks are slower due to design differences between production and local development. For example, the cache used is not the same: I use Flask cache disk locally, which is faster, while my app uses a Redis backend to cache results. Redis introduces additional overhead due to the external request it must handle, compared to just RAM or disk caching on the same device.
• Maybe the request itself is slower due to upload/download speed limits. When deployed, my app is on a remote web server, whereas locally it runs directly on my computer. Obviously, this introduces extra overhead. It’s much faster for my browser to communicate with a local app on the same device as with a remote app over the internet.

So how to debug this?

To make it short, I tried to replicate the issue locally (which is always a good way to debug things). I started by inspecting the triggered callbacks after a click on the map. You might know that all Dash callbacks translate to HTTP requests, so I used the developer tools and network tab to analyze what was happening.

If you don’t know that callbacks translate to HTTP request, I recommend you to download my guide “Master Dash Callbacks: Architecture & Best Practices (Free PDF)” find it on the sidebar —-> or below this article on mobile.

To simulate a “distant” request from my computer to a remote server, I set the network throttling to “Good 3G” to mimic a 3G mobile connection. This was key in debugging. Without this, everything appeared snappy in my browser.

I discovered that eight callbacks were triggered (directly or indirectly) after clicking on the map. Here is the debugging process in video:

As you can see in the video, it literally took around 14 seconds (!!) to complete the eight callbacks after clicking on the map.

Two requests appeared to be blocking the others, leading to huge delays: between 1 and 8 seconds for some callbacks. This is significant.

When inspecting the first request, I quickly realized that the bottleneck was the time spent “Sending” the data: 4.05s. The “Waiting” time (when the browser waits for the server response) was only 64ms. So, the callback processing was not the problem—the data upload was.

When inspecting the second request, I saw that it was also blocked for 4.05s, meaning it was simply not triggered immediately.

The third request showed the same problem as the first one: too much time spent sending data, with only 108ms processing on the server side and no delay in receiving the result.

At this point, it was clear that two callbacks were problematic. To identify which callbacks these HTTP requests were triggering, I inspected the request details. The names of outputs, inputs, and states are visible as part of the information Dash sends with each callback:

I realized that the full map data (map_figure_data) was being sent. For my app, that meant all the points and their hover information (descriptions, images, etc.).

Even though it wasn’t a huge amount of data, it posed two problems:

• Upload speeds are usually slower than download speeds. For slow connections like mobile networks, this delay is unbearable.
• The issue worsens as the number of data points on my map increases (!)

The second callback had the same problem. This time, the map data was an input. The goal was to see how I could eliminate this map_figure_data dependency.

Resolution

I then looked at my two callbacks. Here’s what they originally looked like.

callback 1 – before

@callback(
    Output("map_selection_memory", "data"),
    [
        Input("map", "selectedData"),
        Input("location_data_memory", "data"),
        Input("layer_selection_memory", "data"),
    ],
    [
        State("map_curve_mapping_memory", "data"),
        State("map_selection_memory", "data"),
        State("map_figure_data", "data"),  # the problematic state
    ]
)
def store_map_selection(
    selected_data, location_data, layer, curve_mapping, selected_ids, figure_data
):
    """A callback that Stores the selected ids in memory."""

While reviewing the callback code, I realized that figure_data wasn’t even used. So, I removed it and it solved the problem for this callback… (yes, I guess that these things happens!).

callback 1 – after (removed useless state!)

@callback(
    Output("map_selection_memory", "data"),
    [
        Input("map", "selectedData"),
        Input("location_data_memory", "data"),
        Input("layer_selection_memory", "data"),
    ],
    [
        State("map_curve_mapping_memory", "data"),
        State("map_selection_memory", "data"),
        # just removed the useless state
    ]
)
def store_map_selection(
    selected_data, location_data, layer, curve_mapping, selected_ids
):
    """A callback that Stores the selected ids in memory."""

Now, looking at the second callback.

callback 2 – before

@callback(
    Output("cache_data_metadata_memory", "data"),
    [
        Input("map_figure_data", "data"),  # this is problematic
        Input("map_selection_memory", "data"),
        Input("data_modal_unchecked_memory", "data"),
    ],
    State("address_input_memory", "data"),
    State("layer_selection_memory", "data"),
    State("filters_selection_memory", "data"),
    prevent_initial_call=True,
)
def update_cache_data_metadata_memory(
    fig_data, selected_ids, unchecked_ids, address, layer, filters
):
    """Update metadata dict (...)"""

Again, fig_data wasn’t used. However, I still needed map_figure_data to trigger updates, so I changed the input property to modified_timestamp. This enables the callback to be triggered when map_figure_data changes (its timestamp is updated) while not transferring the whole data.

callback 2 – after (changed to modified_timestamp)

@callback(
    Output("cache_data_metadata_memory", "data"),
    [
        Input("map_figure_data", "modified_timestamp"),  # this is efficient
        Input("map_selection_memory", "data"),
        Input("data_modal_unchecked_memory", "data"),
    ],
    State("address_input_memory", "data"),
    State("layer_selection_memory", "data"),
    State("filters_selection_memory", "data"),
    prevent_initial_call=True,
)
def update_cache_data_metadata_memory(
    map_update_timestamp, selected_ids, unchecked_ids, address, layer, filters
):
    """Update metadata dict (...)"""

And that did the job perfectly!

But what if I actually had to keep the full figure data ? I would have had two choices:

• Create another input, that is lighter than the figure data
• Process the figure data in a clientside callback to avoid a roundtrip to the server.

Result

These changes literally took 20 seconds to implement. The result was instantly better, even with the “Good 3G” mobile throttling still enabled:

After making these adjustments, I ensured there were no other instances of map_figure_data being used as either an Input or Output.

Conclusion

When debugging this issue, I thought it would be an interesting use case to share, because:

• Using developer tools is a powerful way to debug slow callbacks and sluggish Dash apps. Keep in mind that all inputs and states trigger data uploads, which in some cases can be extremely slow.
• Using throttling mode allows you to simulate production conditions or at least non-optimal conditions, unlike debugging locally.

I hope you found this interesting. Such performance explanations and debugging techniques are part of my Dash course, where you can find more detailed explanations and videos.

If you have questions, feel free to ask them here on Plotly’s forum.

Happy coding!

L’article Dash app callback performance: a real-world debugging example est apparu en premier sur dash-resources.com.

In this tutorial, I’ll give you tips and advices to keep in mind to create visually appealing dashboards and Dash apps, to increase the usability and aesthetics of your project.

Introduction

Let’s be honest: most dashboards are functional but completely fail in terms of UI/UX (user interface/user experience). And that’s normal—most of us are data analysts, data scientists, or Python developers, and UI/UX is not our job.

If you are building a dashboard for your own use or designed for technical people, you might not care about aesthetics. But if you want people outside your team to engage with and use the amazing dashboard that you made, you should invest time in making your dashboard visually appealing.

This is even more true if you are creating an app used by non-technical people (not in your field) or if you are developing a SaaS product for a broader audience with Dash.

Fortunately, by following a few rules, you can significantly improve your skills in building beautiful dashboards and apps. Let’s dive in.

Pick a font

The harsh truth: the lack of a personalized font is one of the common traits of ugly dashboards. That’s why I put it at the top of this list. You’ll never see a professional-looking app that sticks to “Times New Roman” (i.e., the default font in most web browsers).

This doesn’t mean this font should never be used, but it means that default fonts quickly show that no effort was put into aesthetics. So, setting a proper font is a real quick win.

Serif fonts often imply tradition and formality (Times New Roman is widely used in newspapers and books, and there’s nothing wrong with that if your app is focused on reports, articles, or anything content-heavy). But usually, dashboards benefit from sans-serif fonts for a cleaner, more modern look.

Recommended fonts are the basic ones:

• Arial, Open Sans, Verdana, Helvetica Neue.

If you need more stylish and trendy fonts, here are some great options:

• Roboto (modern and widely used in web design)
• Lato (clean and friendly, great for dashboards)
• Montserrat (sleek and professional)
• Inter (highly readable and trendy for UI design)

If you need more inspiration, you can explore Google Fonts or Adobe Fonts to find stylish options that fit your dashboard’s aesthetic. But being too exotic is not a good idea either.

Note: You should always set a font because otherwise, your app might look different on various devices (Windows, Mac, Linux, etc.) and browsers, which may pick different default fonts.

Pick colors correctly

No colors is terrible

Colors help with contrast, and contrast is absolutely necessary if you want to ease the eye. A dashboard with no contrast is hard to read, making users tire quickly. If everything looks the same, users won’t know where to focus.

Using just black and white or a single muted color can make your app look dull and unstructured. Instead, introduce some contrast using different shades and tones, but in a subtle way. Use colors to differentiate sections, highlight key metrics, and guide user attention effortlessly.

Too many colors is terrible

On the flip side, throwing in too many colors makes everything look chaotic. Too much contrast can make your dashboard overwhelming and confusing. A rainbow-colored dashboard is not visually appealing—it’s distracting.

Go easy on gradients. Too many gradients will make your app look like outdated WordArt! Use soft gradients sparingly—to highlight a few buttons or text, but not everywhere. Stick to a defined color palette and ensure your colors complement each other.

Importance of color choice

Colors enhance the appearance of your app but also improve user experience: you can emphasize the importance of a button by its color alone, meaning the user instantly understands its significance.

People also associate certain colors with specific actions—red buttons usually indicate critical actions, while blue or black buttons tend to be more neutral. Green often signals success, and yellow can be used for warnings.

Just like fonts, using default colors (100% red, 100% green, or 100% blue) will make your dashboard look unpolished. Instead, pick variants of these colors—softer shades, deeper tones, or slight variations.

Pro tip: If you don’t know what colors to use, you can rely on predefined color palettes from Mantine, Bootstrap, or websites like Flat UI Colors.

Also remember that users have different visual impairments (e.g., color blindness). Learn more about it here: coloring for colorblindness.

Beware of the hierarchy

Hierarchy isn’t just about making titles bigger —it’s about creating a natural flow for the eyes. When someone looks at your dashboard, they should naturally understand what’s important and what’s secondary.

A simple but effective approach is to stick to 3-4 text sizes for your entire app. Your main title should be the biggest (around 32px), followed by section titles (24px), and then your regular text (14-16px). Don’t go smaller than 12px – nobody likes squinting at tiny text!

But size isn’t everything. You can also create hierarchy through weight (bold vs regular) and color intensity. Just like in a newspaper, the most important stuff should catch your eye first.

Think about it: when you look at a well-designed website, you instantly know where to focus, right? That’s good hierarchy at work.

Space things out!

Let your components breathe:

• Add margins around text and padding inside buttons.
• Text should not be stuck to the border of its container—use proper padding and margins.

The easiest way to handle spacing is to pick a basic unit (like 8 pixels) and use multiples of it. Put a little space between related items (8px), more space between different elements (16px), and even more space between major sections (24px or 32px).

Remember: white space isn’t wasted space. It’s like the margins in a book – without them, everything would be a mess and hard to read. Give your components some breathing room. Your users’ eyes will thank you.

Keep things homogeneous

In art, proportions are an integral part of the works of the greatest masters. Many sculptures and paintings, for example, use the golden ratio.

The same applies to interfaces: consistency is key to making dashboards look polished and professional.

But what does this mean in practice?

• Apply the same margins and padding throughout, ensuring a balanced layout while respecting hierarchy.
• Stick to 2-3 main colors with one accent color for emphasis. Example: if you use blue buttons, don’t randomly switch to green unless it serves a purpose.
• Keep shapes and styles uniform—rounded buttons should stay rounded, and shadows should be consistent across cards.

Small details make a big difference!

Remember to style charts too

By default, Plotly charts do not inherit the styles of your app. So, be sure to at least set the font style and colors to match your dashboard.

Also, tweak chart elements like gridlines, legend placement, and axis labels to keep the same spacing you used before (to keep things homogeneous!).

Another pro tip: If your dashboard has multiple charts, keep them consistent in terms of styling. Same font, same color scheme, same layout rules—it all helps with clarity and makes your dashboard look like a professionally designed tool.

Use pre-made components

Last but not least: you should use component libraries like Dash Bootstrap Components (DBC) or Dash Mantine Components (DMC). These libraries come with a lot of default CSS rules and choices, a technic known as a CSS reset.

These rules ensure that HTML elements are correctly placed, well-spaced, have the right font sizes, and maintain a consistent, homogeneous style. Exactly everything we did before, so it will make you gain time.

However, these component libraries are popular which is a good and a bad thing:

• The good: people like them. Remember, users don’t want anything too crazy—they prefer familiar, intuitive designs. They will like your design because they are used to it.
• The bad: all websites look the same. However, with the choices you have (layout, colors, fonts, etc.), you can still make your dashboard unique while keeping it aesthetically pleasant.

My 2 cents: I always use at least DBC or Mantine in my Dash projects, whether I create custom components or not, because they bring a CSS reset and a lot of CSS utils.

See also:

• How to use Dash Bootstrap Components (soon)
• How to use Dash Mantine Components (soon)

Conclusion

Let’s wrap this up with an important reminder: these aren’t strict commandments set in stone. Think of them more as helpful guidelines that, when mixed and matched thoughtfully, can lead to visually appealing dashboards. You don’t need to follow every single rule.

The best way to improve your design skills is to experiment and stay observant. Pay attention to the apps and tools you enjoy using. What makes them pleasant to work with? How do they handle fonts, colors, and spacing? Take inspiration from what works well in your favorite applications.

And here’s a final thought: people tend to find “normal” things beautiful.

• You don’t need to reinvent the wheel or create the most unique dashboard ever seen. Aim for clean, familiar, and professional rather than wildly original.
• A “dash” of creativity is great, but remember that if your dashboard looks too exotic, it might end up being harder to use!

The goal is simply to create something that looks professional and is pleasant to use.

Follow these guidelines, trust your eye, and you’ll be well on your way to creating dashboards that both you and your users will enjoy.

I hope you liked this guide and learn. This is part of my Dash plotly Course, be sure to check it out if you want to learn more about building dashboards.

If you have any question, join us on the dedicated topic on Plotly’s forum: here.

L’article A guide to beautiful Dashboards (basic design principles) est apparu en premier sur dash-resources.com.

You’ll find below a demo video of the app.

Let’s get started!

Prerequisites

Before we begin, make sure you have Python 3.9 or later installed. We then need the following:

• Dash Plotly: the best Python framework for building interactive web apps and dashboards;
• Dash-chat component: a community-supported tool for creating chat user interfaces (UI);
• OpenAI package: used to retrieve responses from OpenAI GPT models.

Important : you’ll need an OpenAI API key to run the following code. You can get one from the OpenAI platform.

Step 1: Setting up the Environment

First, let’s install the packages using pip:

pip install dash dash-chat openai

Then, let’s import our required packages and set up our OpenAI client:

import os
import dash
from dash import callback, html, Input, Output, State, dcc
from dash_chat import ChatComponent
from openai import OpenAI

# Initialize OpenAI client
api_key = os.environ.get("OPENAI_API_KEY")
client = OpenAI(api_key=api_key)

Note: We’re getting the API key from environment variables for security. It’s a best practice not to hardcode keys in your code to avoid sharing it by mistaking.

Step 2: Creating the application layout

Next, we’ll create our Dash application and define its layout:

app = dash.Dash(__name__)

# Define default messages for the chat
default_messages = [
    {"role": "assistant", "content": "Hello!"},
]

app.layout = html.Div(
    [
        ChatComponent(
            id="chat-component",
            messages=[]  # Initialize empty since we'll load from storage
        ),
        
        # The store component help use save messages
        dcc.Store("chat-memory", data=default_messages, storage_type="local"),
    ],
    
    # Some basic CSS styling for the app
    style={
        "max-width": "800px",
        "margin": "0 auto",
        "font-family": "Arial, sans-serif",
        "padding": "20px",
    }
)

The Dash Chat component follows the same structure as the OpenAI conversation API with role and content. The AI messages will have role="assistant" while the user messages will have role="user".

Instead of passing the messages directly to the ChatComponent, we save them into a dcc.Store component. This component will enable us to persist the messages in the browser’s session: the discussion will still show up if we reload the page, but will be cleared if we close the tab/browser.

Good to know: setting storage type to “local” enable saving the discussion even when the browser is closed. You might want to create a reset button if you do so!

We also added basic CSS styling for the app. In Dash, you can either add styling with the style parameters on most components or include your styles in an external stylesheet (see more).

Step 3: Implementing the chat callback

Callbacks make Dash applications interactive by linking Input components (user actions) to Output components (updates in the app) while handling logic on the server:

• Input triggers a callback based on user actions, such as typing a message in the chat.
• Output defines what part of the app updates, like refreshing the chat interface with new messages.
• State retrieves current values without triggering a callback, useful for accessing stored data like chat history.

Here’s how it works:

@callback(
    Output("chat-component", "messages"),
    Output("chat-memory", "data"),
    Input("chat-component", "new_message"),
    State("chat-memory", "data")
)
def handle_chat(new_message, messages):
    # If new_message is None, just return the stored messages
    # This is run at page load
    if not new_message:
        return messages, messages

    # If we have a user message, concatenate it to the list of messages
    updated_messages = messages + [new_message]

    # If the new message comes from the user, trigger the OpenAI API
    if new_message["role"] == "user":
        # We use the OpenAI completion API to get an answer to the user message
        response = client.chat.completions.create(
            model="gpt-4",
            messages=updated_messages,
        )
        bot_response = {
            "role": "assistant",
            "content": response.choices[0].message.content.strip()
        }

        # Append the new message to the message list
        updated_messages += [bot_response]

    # We update both the chat component and the chat memory
    return updated_messages, updated_messages

In this case, our input is the chat user input, provided by dash-chat component. The processing achieved by the callback will involve retrieving an answer from the OpenAI API, and the output is the updated list of messages.

Straightforward and simple

Learn more on callbacks with this tutorial: Dash callbacks, schemas and examples.

Step 4: Running the app

We finally add the code to run our server:

if __name__ == "__main__":
    app.run_server(debug=True)

Here is the result:

You can try reloading the page; you’ll see the chat output is kept. But if you close the tab, a new session will be created next time.

Full code

You can download the full code below, with guided instructions on how to run the app:

Going further

Here are a few ideas to improve this chat app:

• add a “clear chat” button that triggers a callback which reset the messages sent ;
• add an input to join a file, so that the AI can answer based on content ;
• save messages in a proper database instead of browser storage.

The Dash Chat component is a recent work in progress, so be sure to check out the coming updates here.

Conclusion

I hope this short tutorial convinced you how easy and beginner-friendly it is to build a chatbot app with Dash plotly! With just a few lines of Python, you can create an interactive, AI-powered chat interface that works seamlessly in the browser.

Dash plotly can be used for both small data apps, AI apps, dashboard or real SaaS applications. It makes it easy to connect frontend and backend with pure Python. Check-out all the examples on plotly’s website: https://plotly.com/examples/

If you want more inspiration, here are a few other apps:

• A classic Todo app: A simple yet powerful app to manage your daily tasks, showcasing Dash’s flexibility for non-AI use cases.
• QuizDash: A fun app that generates quizzes on any topic using the OpenAI API.
• StockSaavy: An AI powered chat-agent that answers questions about recent news articles pertaining to stocks in the S&P500.

Happy coding!

L’article Build a chatbot web app under 5min in Python est apparu en premier sur dash-resources.com.

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.