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 article, I’ll show you how you can improve the user interface and user experience (UI/UX) of a DataTable by tweaking some parts using CSS ( interactive app below )

Let’s dive in!

1 – Add Bootstrap styles

First things first: the DataTable’s basic styles don’t integrate well with an app. The main reason is that many styles, such as the font-family, are hardcoded.

If you work with Dash Bootstrap Components, this becomes obvious. Let’s take a simple app as an example:

import pandas as pd
import numpy as np
import dash_bootstrap_components as dbc
from dash import Dash, html, Input, Output, dash_table

# Create sample data
np.random.seed(42)
size = 20
df = pd.DataFrame({
    "id": range(size),
    "x": np.random.normal(0, 1, size),
    "y": np.random.normal(0, 1, size),
    "category": np.random.choice(["A", "B", "C"], size)
})

# Initialize the Dash app
app = Dash(__name__, external_stylesheets=[dbc.themes.BOOTSTRAP])

# Define the layout
app.layout = html.Div(
    [
        # Data table
        html.Div(
            dash_table.DataTable(
                id="table",
                columns=[
                    {"name": i, "id": i, "deletable": True, "selectable": True} for i in df.columns
                ],
                data=df.to_dict("records"),

                # Enable multi-row selection and paging
                filter_action="native",
                sort_action="native",
                sort_mode="multi",
                column_selectable="multi",
                row_selectable="multi",  
                page_action="native",
                page_size=10,
            ),
            id="table_container",
        )
    ],
    className="container"
)

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

The solution is to overwrite the DataTable’s styles with Bootstrap styles. Fortunately, Ann Marie Ward, a major Dash contributor, has already created a solution for this here ( thank you Ann if you see this ).

Her CSS stylesheet includes styles to apply Bootstrap themes to Dash components, such as tables and buttons, for a consistent appearance. We’ll download it (link), and save into into the assets folder at assets/dbc.css.

Then, we just need to add the dbc CSS class to a container div wrapping our DataTable:

# Data table
html.Div(
    dash_table.DataTable(
        # ...
    ),
    id="table_container",
    className="dbc"  # we added the dbc class
)

As you can see, the table now inherits the Bootstrap styles. However, the pagination remains untouched.

Unfortunately, there is no option to dynamically set the className of the buttons to Bootstrap’s btn, btn-outline-primary, and btn-sm. But we can copy their styles (e.g., from the Bootstrap documentation) and apply them to the four pagination buttons (.first-page, .next-page, .previous-page, .last-page):

/* reset font styles on pagination buttons */
.dbc .dash-table-container .previous-next-container .page-number,
.dbc .dash-table-container .previous-next-container .page-number .current-page-container input.current-page {
    font-family: var(--bs-body-font-family);
    font-size: var(--bs-body-font-size);
    font-weight: var(--bs-body-font-weight);
    line-height: var(--bs-body-line-height);
    min-width: auto !important;
}

/* apply the same styles as .btn, .btn-sm, .btn-outline-primary */
.dbc .dash-table-container .previous-next-container {
    button {
        &.first-page,
        &.last-page,
        &.previous-page,
        &.next-page {
            display: inline-block;
            font-weight: 400;
            text-align: center;
            vertical-align: middle;
            user-select: none;
            padding: 0.25rem 0.5rem;
            margin: 0 0.25rem;
            font-size: 0.875rem;
            line-height: 1.5;
            border-radius: 0.2rem;
            transition: color 0.15s ease-in-out, background-color 0.15s ease-in-out, border-color 0.15s ease-in-out, box-shadow 0.15s ease-in-out;
            color: var(--bs-primary);
            border: 1px solid var(--bs-primary);
            background-color: transparent;

            &:hover {
                color: var(--bs-white) !important; /* override dbc.css */
                background-color: var(--bs-primary);
                border-color: var(--bs-primary);
            }

            &:focus {
                box-shadow: 0 0 0 0.25rem var(--bs-primary-rgb, rgba(13, 110, 253, 0.25));
            }

            &:active,
            &.active {
                color: var(--bs-white);
                background-color: var(--bs-primary);
                border-color: var(--bs-primary);
            }

            &:disabled,
            &.disabled {
                color: var(--bs-primary);
                background-color: transparent;
                border-color: var(--bs-primary);
                opacity: 0.65;
                pointer-events: none;
            }
        }
    }
}

CSS rules are applied by order of importance (priority) to an element. The more you add precision to the selection, the more weight the rule has:

/* a rule targetting a button */
.dash-table-container button { ... }
/* equivalent, but more precise (more weight): */
body .dash-table-container .previous-next-container button {...} 

That’s why sometimes we see a long selector definition, and sometimes not —because in some cases, it’s too complex to increase the weight of a rule. Then !important keyword enable us to override some CSS properties without having to make a stronger rules.

Good to know: It’s better to avoid !important whenever possible because each use makes future overrides more complex. Imagine if the creators of Bootstrap had used !important everywhere—overriding their styles would have been a nightmare!

Now let’s visualize the result:

We now have a Bootstrap-styled DataTable. Much better!

2 – Improve the header

There are a few things I don’t like about the default DataTable header, but thankfully, everything is fixable with CSS.

First, the header row should be highlighted:

/* make the heading bold and with a gray background */
.header-style .dash-table-container th {
    background-color: var(--bs-gray-200) !important;
}

.header-style .dash-table-container th .column-header-name {
    font-weight: bold;
}

.header-style .dash-table-container th input::placeholder {
    /* overrides back a style set in dbc.css */
    background-color: transparent !important;
}

If you are not familiar with CSS variables, take a look at this documentation. They allow using the Bootstrap without hardcoding them. It is useful for themes like dark/light themes that will only require a change of variable value.

Second, the icons in the header are not uniformly sized, vertically aligned, or evenly spaced. Let’s fix that:

/* better homogeneous styling of buttons */
.header-style .column-actions {
    /* let us breath! */
    gap: 0.4em; 
    margin-right: 0.5em;
}

.header-style .column-actions > span {
    /* align components vertically */
    display: flex;
    flex-direction: column;
    justify-content: center;
}

.header-style .dash-table-container th input[type="radio"],
.header-style .dash-table-container th input[type="checkbox"] {
		/* fix inconsistent color and size */
    width: 1rem;
    height: 1rem;
    opacity: 0.6;
}

.header-style .dash-table-container th input[type="radio"]:checked,
.header-style .dash-table-container th input[type="checkbox"]:checked {
		/* when checked, reset opacity */
    opacity: 1;
}

Finally, clicking on the case-sensitive filter (aA) causes the column width to change. Adding a transparent border of the same size resolves this issue:

.header-style .dash-table-container .dash-spreadsheet-container .dash-spreadsheet-inner th.dash-filter input.dash-filter--case--insensitive {
    /* avoid column width size change when clicking */
    border-style: solid;
    border-width: 2px;
    border-color: transparent;
}

Remember the CSS weights for rules? The definition above is long on purpose: thanks to this, I don’t need to add !important.

Here is the result:

At this point, there are two types of people: those who notice the differences and those who don’t. If you don’t, I don’t blame you—you live in a much simpler world than I do!

If you do notice the differences, you may experience the satisfaction of seeing these buttons properly arranged.

3 – Striped rows

Displaying striped rows can make the table easier on the eyes. It’s a tiny detail, but combined with other enhancements (like mouseover color), it improves the overall user experience of your app.

Striped rows for the DataTable can be achieved in Python, but a simple CSS snippet will also do the job:

/* Alternating row background */
.striped-style .dash-table-container td:not(.cell--selected) {
    background-color: transparent !important;
}

.striped-style .dash-table-container tr:nth-child(odd) {
    background-color: var(--bs-gray-100) !important;
}

.striped-style .dash-table-container tr:nth-child(even) {
    background-color: var(--bs-body-bg) !important;
}

The CSS property :nth-child is the key here, as it allow selecting either odd or even rows tr. The cells td are made transparent as the background is changed at the row level.

4 – Hover effect

Adding a hover effect is a simple trick to enhance interactivity, even for static tables. It implicitly signals to the user that the table is interactive.

Here’s the CSS to add a hover effect:

/* Hover row background */
.hover-style .dash-table-container tr:hover td:not(.cell--selected)  {
    background-color: var(--bs-gray-200) !important;
}

The background is applied to all cells expect selected cells (i.e., active cells), using td:not(.cell—selected).

The hover color is slightly darker (—bs-gray-200 instead of —bs-gray-100) to remain visible even on striped rows.

5 – Row selection

By default, clicking on a cell highlights it. However, in most cases, it’s more intuitive to highlight the entire row. It is also helpful to emphasize rows selected via the left checkboxes. Let’s address this.

This code is slightly more complex:

• We style rows that have the .cell--selected class. This includes rows selected via checkboxes or mouse clicks.
• To avoid overlapping borders, we use the adjacent sibling selector (+) to remove duplicate borders. For example, instead of |X||X|, we get |X|X|.

/* apply style to selected cell */
.selection-style .dash-table-container tr:has(td.cell--selected) td.cell--selected {
    background-color: rgba(var(--bs-primary-rgb), 0.2) !important;
    border: 1px solid var(--bs-primary) !important;
    outline: none !important;
}

/* apply styles to the other cells of selected rows */
.selection-style .dash-table-container tr:has(td.cell--selected) td {
    background-color: rgba(var(--bs-primary-rgb), 0.2) !important;
    border: 1px solid #d0d0d0 !important;
}

/* remove border between selected cells (vertically) */
.selection-style .dash-table-container tr:has(td.cell--selected) + tr:has(td.cell--selected) td.cell--selected {
    background-color: rgba(var(--bs-primary-rgb), 0.2) !important;
    border-top: none !important;
}

/* remove border between selected cells (horizontally) */
.selection-style .dash-table-container tr:has(td.cell--selected) td.cell--selected + td.cell--selected {
    border-left: none !important;
}

/* apply style to checked rows */
.selection-style .dash-table-container tr:has(input:checked) td {
    background-color: rgba(var(--bs-primary-rgb), 0.1) !important;
    border: 1px solid #d0d0d0 !important;
}

Most styles here use !important to remain compatible with the dbc.css styles. If we don’t keep the dbc.css styles, additional lines would be required for proper functionality:

/* add dbc styles to selection-style */
body .selection-style .dash-table-container .dash-spreadsheet-container .dash-spreadsheet-inner td {
    background-color: var(--bs-body-bg);
    color: var(--bs-body-color);
    border: var(--bs-border-width) solid var(--bs-border-color) !important;
}
.selection-style .dash-table-container .dash-spreadsheet-container .dash-spreadsheet-inner table {
    border-collapse: inherit;
    border-spacing: unset;
}

The selection works for rows selected via checkboxes, single mouse clicks, and multiple selections (holding Shift).

Notice that row selection do not work well visually with striped rows, so I removed it from the above screenshot. Feel free to try it yourself with the interactive app!

How to modify styles yourself

You might wonder how I came up with these precise CSS rules while reading this article.

Overriding CSS styles involves trial and error. Essentially, you need to use developer tools to inspect the applied rules on the target element and figure out how to “override” those rules.

Here’s how you can do it :

1. Right click in the browser on the element > Inspect
2. Select the element in the browser in the list if necessary
3. Look at the CSS styles applied to this element.

CSS rules are applied in order of priority. Inline styles (applied directly to the element) usually take precedence. Overridden styles are shown as struck-through in developer tools, indicating which rule has the highest priority.

You can also use developer tools to copy styles from another source (as I did for Bootstrap):

If you want to know more about this debugging process, please send an article request.

How to reuse this code

Each part of the styling corresponds to a specific class. This means you can copy and paste the code and simply add the relevant class name: dbc(for the Bootstrap style), header-style, striped-style, hover-style and selection-style.

Example with all styles except striped rows:

# Data table
html.Div(
    dash_table.DataTable(
        # ...
    ),
    id="table_container",
    className="dbc header-style hover-style selection-style" # all styles except striped rows
)

You can also play with the interactive app below to see the differences (or click here):

Click here to see the final CSS code

/* Author: Fran from dash-resources.com 
 * Originally posted in: https://dash-resources.com/improving-dash-datatables-simple-css-tweaks/
 */

/* ------------------------------------------------*/
/* Bootstrap style */

/* reset font styles on pagination buttons */
.dbc .dash-table-container .previous-next-container .page-number,
.dbc .dash-table-container .previous-next-container .page-number .current-page-container input.current-page {
    font-family: var(--bs-body-font-family);
    font-size: var(--bs-body-font-size);
    font-weight: var(--bs-body-font-weight);
    line-height: var(--bs-body-line-height);
    min-width: auto !important;
}

/* apply the same styles as .btn, .btn-sm, .btn-outline-primary */
.dbc .dash-table-container .previous-next-container {
    button {
        &.first-page,
        &.last-page,
        &.previous-page,
        &.next-page {
            display: inline-block;
            font-weight: 400;
            text-align: center;
            vertical-align: middle;
            user-select: none;
            padding: 0.25rem 0.5rem;
            margin: 0 0.25rem;
            font-size: 0.875rem;
            line-height: 1.5;
            border-radius: 0.2rem;
            transition: color 0.15s ease-in-out, background-color 0.15s ease-in-out, border-color 0.15s ease-in-out, box-shadow 0.15s ease-in-out;
            color: var(--bs-primary);
            border: 1px solid var(--bs-primary);
            background-color: transparent;

            &:hover {
                color: var(--bs-white) !important; /* override dbc.css */
                background-color: var(--bs-primary);
                border-color: var(--bs-primary);
            }

            &:focus {
                box-shadow: 0 0 0 0.25rem var(--bs-primary-rgb, rgba(13, 110, 253, 0.25));
            }

            &:active,
            &.active {
                color: var(--bs-white);
                background-color: var(--bs-primary);
                border-color: var(--bs-primary);
            }

            &:disabled,
            &.disabled {
                color: var(--bs-primary);
                background-color: transparent;
                border-color: var(--bs-primary);
                opacity: 0.65;
                pointer-events: none;
            }
        }
    }
}

/* ------------------------------------------------*/
/* Header style 
 * Notice we use !important to override the default style and those written in the dbc.css file
 */

/* make the heading bold and with a gray background */
.header-style .dash-table-container th {
    background-color: var(--bs-gray-200) !important;
}

.header-style .dash-table-container th .column-header-name {
    font-weight: bold;
}

.header-style .dash-table-container th input::placeholder {
    /* overrides back a style set in dbc.css */
    background-color: transparent !important;
}

/* better homogeneous styling of buttons */
.header-style .column-actions {
    /* let us breath! */
    gap: 0.4em; 
    margin-right: 0.5em;
}

.header-style .column-actions > span {
    /* align components vertically */
    display: flex;
    flex-direction: column;
    justify-content: center;
}

.header-style .dash-table-container th input[type="radio"],
.header-style .dash-table-container th input[type="checkbox"] {
    /* fix inconsistent color and size */
    width: 1rem;
    height: 1rem;
    opacity: 0.6;
}

.header-style .dash-table-container th input[type="radio"]:checked,
.header-style .dash-table-container th input[type="checkbox"]:checked {
        /* when checked, reset opacity */
    opacity: 1;
}

.header-style .dash-table-container .dash-spreadsheet-container .dash-spreadsheet-inner th.dash-filter input.dash-filter--case--insensitive {
    /* avoid column width size change when clicking */
    border-style: solid;
    border-width: 2px;
    border-color: transparent;
}

/* ------------------------------------------------*/
/* Alternating row background */
.striped-style .dash-table-container td:not(.cell--selected) {
    background-color: transparent !important;
}

.striped-style .dash-table-container tr:nth-child(odd) {
    background-color: var(--bs-gray-100) !important;
}

.striped-style .dash-table-container tr:nth-child(even) {
    background-color: var(--bs-body-bg) !important;
}

/* ------------------------------------------------*/
/* Hover row background */
.hover-style .dash-table-container tr:hover td:not(.cell--selected)  {
    background-color: var(--bs-gray-200) !important;
}

/* ------------------------------------------------*/
/* Selected row style */

/* apply style to selected cell */
.selection-style .dash-table-container tr:has(td.cell--selected) td.cell--selected {
    background-color: rgba(var(--bs-primary-rgb), 0.2) !important;
    border: 1px solid var(--bs-primary) !important;
    outline: none !important;
}

/* apply styles to the other cells of selected rows */
.selection-style .dash-table-container tr:has(td.cell--selected) td {
    background-color: rgba(var(--bs-primary-rgb), 0.2) !important;
    border: 1px solid #d0d0d0 !important;
}

/* remove border between selected cells (vertically) */
.selection-style .dash-table-container tr:has(td.cell--selected) + tr:has(td.cell--selected) td.cell--selected {
    background-color: rgba(var(--bs-primary-rgb), 0.2) !important;
    border-top: none !important;
}

/* remove border between selected cells (horizontally) */
.selection-style .dash-table-container tr:has(td.cell--selected) td.cell--selected + td.cell--selected {
    border-left: none !important;
}

/* apply style to checked rows */
.selection-style .dash-table-container tr:has(input:checked) td {
    background-color: rgba(var(--bs-primary-rgb), 0.1) !important;
    border: 1px solid #d0d0d0 !important;
}

/* add dbc styles to selection-style */
body .selection-style .dash-table-container .dash-spreadsheet-container .dash-spreadsheet-inner td {
    background-color: var(--bs-body-bg);
    color: var(--bs-body-color);
    border: var(--bs-border-width) solid var(--bs-border-color) !important;
}
.selection-style .dash-table-container .dash-spreadsheet-container .dash-spreadsheet-inner table {
    border-collapse: inherit;
    border-spacing: unset;
}

Conclusion

I hope this article showed how far you can go with CSS to override predefined styles. Even though it’s not perfect, small enhancements like these can significantly improve the user interface and user experience of your dashboard or app.

Feel free to contact me if you have suggestions for this code. Don’t forget to subscribe to get notified about new articles!

Happy Dash coding

L’article Improving Dash DataTables: Simple CSS Tweaks 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.

Over the years, I’ve developed and maintained apps either on my own or with different teams. In this tutorial, I’ll share five good practices, based on my experience, to help you better organize your Dash callbacks.

See also: Dash development best practices

Let’s dive in!

1. Separate layouts from callbacks

It’s really common to see callbacks, layouts, and data processing in the same file. Many people develop the first version of their app quickly, and it’s too early to think about organization. However, if your plan is to make the application easy to maintain, you must adopt a better project structure.

There are many ways to achieve this. I personally follow something that resembles the MVC pattern:

• Create new folders: callbacks, layouts, and utils.
• Create separate files for each part of your app in the callbacks and layouts folders.

Example

The following is an example architecture. The one that I personnaly use in my projects is very similar:

# Example folder structure
app/
  ├── callbacks/
  │   ├── sales_dashboard.py    # All sales-related callbacks
  │   ├── inventory.py          # All inventory-related callbacks
  │   └── user_settings.py      # User preferences callbacks
  ├── layouts/
  │   ├── sales_dashboard.py    # Sales dashboard layout
  │   ├── inventory.py          # Inventory management layout
  │   └── user_settings.py      # Settings page layout
  ├── utils/
  │   └── data_utils.py         # Data preprocessing functions
  └── app.py

In the app.py file, the code becomes more readable:

# app.py
from dash import Dash
from layouts.sales_dashboard import get_sales_dashboard_layout
from layouts.inventory import get_inventory_layout
from layouts.user_settings import get_user_settings_layout
from callbacks.sales_dashboard import *
from callbacks.inventory import *
from callbacks.user_settings import *

app = Dash(__name__)
app.layout = html.Div([
    get_sales_dashboard_layout(),
    get_inventory_layout(),
    get_user_settings_layout(),
])

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

With this architecture, callbacks centralize the logic of each part of the app. They rely on utils to load and process data and layouts functions to update graphs, tables, etc.

See below for an example callback in callbacks/sales_dashboard.py.

2. Make your callbacks readable

It’s common to start doing everything within the callback. This results in many callbacks with 10-50 lines of code, making them hard to read. A good rule of thumb is to keep a callback concise and clear.

You should be able to understand what the callback does just by looking at the inputs, outputs, and a few lines of code (as in the previous example).

Example

Here’s an example. How much time do you need to understand the following callback?

# Hard-to-read callback - too much happening
@app.callback(
    Output('sales-graph', 'figure'),
    [Input('date-picker', 'value'),
     Input('product', 'value')]
)
def update_graph(date, product):
    # Load data
    df = pd.read_csv('sales.csv')

    # Complex data processing inside callback
    df['date'] = pd.to_datetime(df['date'])
    df = df[df['date'] >= date]
    df = df[df['product'] == product]

    # Calculate metrics
    total_sales = df['amount'].sum()
    avg_sale = df['amount'].mean()

    # Create figure with multiple traces
    fig = go.Figure()
    fig.add_trace(go.Scatter(x=df['date'], y=df['amount'], name='Sales'))
    fig.add_trace(go.Scatter(x=df['date'], y=df['amount'].rolling(7).mean(), name='7-day average'))

    # Complex layout settings
    fig.update_layout(
        title=f'Sales for {product}: Total ${total_sales:,.2f}, Average ${avg_sale:.2f}',
        xaxis_title='Date',
        yaxis_title='Amount',
        hovermode='x unified'
    )
    return fig

I’m pretty sure it took some time. Now let’s outsource each part into functions saved in other files (following advice #1):

# callbacks/sales_dashboard.py
from layouts.sales_dashboard import create_sales_figure
from utils.data_utils import load_and_filter_data   

@app.callback(
    Output('sales-graph', 'figure'),
    [Input('date-picker', 'value'),
     Input('product', 'value')]
)
def update_graph(date, product):
    df = load_and_filter_data(date, product)
    fig = create_sales_figure(df)
    return fig

Now, how much time did it take you to understand this code?

The callback function doesn’t even need to be commented. The code speaks for itself, is easily understandable, and is easy to maintain. Future developers on the project will immediately understand what is going on!

3. Don’t oversplit callbacks

I generally advocate for a “divide-and-conquer” approach, which encourages making small, atomic functions. However, in the case of callbacks, it’s not always the best option. Making small callbacks increases the number of HTTP requests needed, thus increasing latency and unnecessary server rounds.

Example

Here’s an example. The first version splits a simple calculation into two callbacks, creating unnecessary complexity:

# Unnecessarily split version
@app.callback(
    Output('temp-celcius', 'children'),
    Input('temperature', 'value')
)
def convert_to_celsius(fahrenheit):
    celsius = (fahrenheit - 32) * 5/9
    return f"{celsius:.1f}°C"

@app.callback(
    Output('temp-kelvin', 'children'),
    Input('temp-celcius', 'children')
)
def convert_to_kelvin(celsius_text):
    celsius = float(celsius_text.replace('°C', ''))
    kelvin = celsius + 273.15
    return f"{kelvin:.1f}K"

Let’s rewrite this as a single callback:

# Better as one callback
@app.callback(
    [Output('temp-celcius', 'children'),
     Output('temp-kelvin', 'children')],
    Input('temperature', 'value')
)
def convert_temperature(fahrenheit):
    celsius = (fahrenheit - 32) * 5/9
    kelvin = celsius + 273.15
    return f"{celsius:.1f}°C", f"{kelvin:.1f}K"

This version combines the conversions into a single callback. It simplifies the code, eliminates the need for string parsing, and reduces the number of callback executions. The calculations are closely related and simple enough that splitting them provides no benefit.

4. Avoid big callbacks too

On the other hand, making big callbacks that handle everything isn’t a good option either. But how do you know if a callback should be split or restructured?

A good rule of thumb is to aim for callbacks with inputs and outputs that naturally group together, i.e., share the same purpose.

Example

Here’s an example. This callback handles both the update of a chart and the creation of an alert:

# Bad example: One callback doing too many unrelated things
@app.callback(
    [Output('sales-chart', 'figure'),
     Output('alerts', 'children')],
    [Input('date-range', 'value'),
     Input('threshold', 'value')]
)
def update_everything(date_range, threshold):
    # This callback mixes two very different responsibilities:
    # 1. Sales visualization
    # 2. Alert system for unusual patterns

    sales_data = get_sales_data(date_range)

    # Create sales visualization
    fig = create_sales_chart(sales_data)

    # Also handle complex alert logic
    unusual_patterns = detect_anomalies(sales_data, threshold)
    alert_messages = generate_alert_messages(unusual_patterns)

    return fig, alert_messages

Now let’s split this callback into two, each with a separate purpose:

# Better: Split into two callbacks with clear, separate purposes
@app.callback(
    Output('sales-chart', 'figure'),
    Input('date-range', 'value')
)
def update_sales_chart(date_range):
    # Only handles visualization
    sales_data = get_sales_data(date_range)
    return create_sales_chart(sales_data)

@app.callback(
    Output('alerts', 'children'),
    [Input('date-range', 'value'),
     Input('threshold', 'value')]
)
def update_alerts(date_range, threshold):
    # Only handles the alert system
    sales_data = get_sales_data(date_range)
    unusual_patterns = detect_anomalies(sales_data, threshold)
    return generate_alert_messages(unusual_patterns)

Even though the original code avoids repetition and combines a common input (date-range), it is badly designed. Poor design will eventually complicate debugging. The split version brings the following benefits:

• Each callback has its own clear purpose → easier to add functionalities in the future.
• Debugging one callback is easier as it has no impact on the other.
• Visualization can be updated without re-triggering the alert logic, and vice versa.

The key takeaway is that callbacks should be split when they handle logically separate features, not just to make them smaller.

5. Chain callbacks intelligently

The way we chain callbacks in Dash Plotly can sometimes resemble the goto instruction in programming languages like C. The goto statement allows the program to jump arbitrarily from one part of the code to another, a practice often criticized for leading to “spaghetti code“—code that is difficult to debug, understand, and maintain.

Dash’s callback system, while powerful, can introduce similar challenges if not carefully managed. As callbacks depend on specific input-output relationships, a poorly structured app can quickly become tangled and confusing, with callbacks triggering each other in complex and unintended ways.

Here is a list of ideas to avoid this:

• If you follow advice n°2, try to avoid chaining callbacks from a callback file to another callback file.
• Avoid connecting a bottom component with a top callback. Instead, try to compute the information of this component upfront.
• As the code changes, some inputs may not be required anymore for a callback. Removing useless inputs will reduce the overall complexity of the app.
• Changing an Input to a State when it’s not needed can as well reduce the complexity of an app.

Example

Let’s see take a look at this code :

# Poor callback organization - "spaghetti" chaining
# callbacks_layout1.py
@app.callback(
    Output('top-chart', 'figure'),
    Input('date-picker', 'value')
)
def update_top_chart(date):
    return create_top_figure(date)

# callbacks_layout2.py
@app.callback(
    Output('middle-stats', 'children'),
    Input('top-chart', 'clickData')
)
def update_middle_stats(click_data):
    point = click_data['points'][0]
    return calculate_stats(point)

# callbacks_layout3.py
@app.callback(
    Output('bottom-table', 'data'),
    Input('middle-stats', 'children')
)
def update_bottom_table(stats):
    # Fragile: depends on parsing text from middle component
    value = float(stats.split(': ')[1])
    return get_table_data(value)

The first version creates a chain of dependencies across different files, where each component waits for updates from the previous one. This makes the code fragile (parsing text from UI elements), hard to debug (dependencies spread across files), and inefficient (cascading updates).

The improved version:

# Better organization - reduce dependencies, compute data upfront
# callbacks.py
def get_full_data(date):
    """Compute all required data at once"""
    df = load_data(date)
    return {
        'chart_data': prepare_chart_data(df),
        'stats': calculate_stats(df),
        'table_data': prepare_table_data(df)
    }

@app.callback(
    [Output('top-chart', 'figure'),
     Output('middle-stats', 'children'),
     Output('bottom-table', 'data')],
    Input('date-picker', 'value')
)
def update_dashboard(date):
    data = get_full_data(date)
    return (
        create_top_figure(data['chart_data']),
        format_stats(data['stats']),
        data['table_data']
    )

# If click interaction is needed, keep it separate
@app.callback(
    Output('detail-view', 'children'),
    Input('top-chart', 'clickData')
)
def show_details(click_data):
    if click_data is None:
        return "Click a point for details"

The improved version front-loads data processing and groups related callbacks together. By streamlining dependencies and keeping data flow clear, while separating interactive features, the code becomes more maintainable.

6. Other good practices

Avoid using suppress_callback_exceptions

I think it’s not a good practice to use suppress_callback_exceptions. If a component is missing but shouldn’t be, this should raise an error. Explicit errors help you understand the problem more quickly. Implicit errors will waste your time.

If you can’t avoid setting suppress_callback_exceptions=True, it likely means you need to rethink your app layout. You could rely on pattern-matching callbacks for components created at runtime.

Use prevent_initial_call when possible

Dash executes callbacks at least once during app initialization by default. If a callback doesn’t need to be executed at first, you can disable its initial execution with prevent_initial_call. This reduces the number of initial callbacks triggered during loading.

Use PreventUpdate

PreventUpdate is a great way to catch errors, e.g., when a value is None or isn’t supposed to be what it is.

Using PreventUpdate helps stop unnecessary callback chaining, reducing the number of updates and HTTP requests. This is a performance tip, but it also simplifies debugging.

Use dcc.Store

You can sometimes use dcc.Store to compute and store results. If the stored data is based on inputs, you instantly reduce the number of inputs needed for dependent callbacks, making them more readable.

However, avoid saving heavy data in dcc.Store (e.g., keep it under 1 MB). Large data slows down the app because it must be both downloaded and uploaded from the client.

Conclusion

What you need to remember is that half the work of keeping callbacks easy to understand is using a well-organized structure.

• Don’t wait too long to refactor your callback functions. If they get too big, externalize functions to make the callbacks easier to read.

• Don’t oversplit logic into many callbacks, but avoid processing everything in a single callback with all inputs and outputs either. Remember the general rule of thumb to create “natural groups”.

Everything presented in this article isn’t an absolute truth. As the framework evolves, so do best practices. But this should help you grow your app from a simple single-page dashboard into a full interactive platform.

I hope you learned something from this article! Be sure to subscribe to the newsletter to see the next ones, and check out the courses.

L’article Dash callbacks best practices (with examples) est apparu en premier sur dash-resources.com.