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.

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.

There are many ways to design Dash callbacks, and in this dash callbacks tutorial, I’ll provide a comprehensive, step-by-step guide with diagrams and code examples.

By the end of this tutorial, you’ll have a good understanding of how callbacks work and how to implement interactivity in your own Dash applications.

Let’s start!

A simple callback

To get started, let’s explore a minimal Dash app that features a simple counter and a button to increment its value:

The associated code is the following:

from dash import Dash, html, callback, Input, Output, PreventUpdate

app = Dash(__name__)

# Declare the layout
app.layout = html.Div([
    html.P('Count: 0', id='counter'),
    html.Button('Click', id='btn', n_clicks=0)
])

# Define the callback
@app.callback(
    Output('counter', 'children'), 
    Input('btn', 'n_clicks')
)
def update(n_clicks):
    return f"Count: {n_clicks}"

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

The first lines define the app layout. The syntax is highly inspired by HTML elements, but elements are called “components” in Dash. These components are more than just static elements; they are interactive and seamlessly integrate with Python callbacks to enable dynamic updates.

app.layout = html.Div([
    html.P('Count: 0', id='counter'),  # same as <p id="counter">Count: 0</p> in HTML
    html.Button('Click', id='btn', n_clicks=0)  # same as <button id="btn">Click</button> in HTML
])

We explicitly set n_clicks to 0 to initialize the button with a default value. Without this, its value would be None, but the update function is supposed to work with an integer.

The next lines define the callback, which is a core concept in Dash. Dash callbacks are just regular Python functions decorated with the @app.callback decorator (or just @callback). This decorator connects input components (such as button clicks) with output components (like the displayed counter text):

@app.callback(
    # the parameters are explicitly written now, but usually we don't
    Output(component_id='counter', component_property='children'), 
    Input(component_id='btn', component_property='n_clicks'),
)
def update_counter(n_clicks):
    # ...

Inputs and Outputs must have a specified component ID and property to connect. This makes it clear which actions update the app and what parts of the app are changed. For example, the button’s n_clicks property triggers the callback, updating the paragraph’s children property with the new count.

If you are not familiar with decorators, I suggest you take a look at this tutorial: https://realpython.com/primer-on-python-decorators/

Dash callbacks are essential as they enable interactivity. By linking inputs and outputs, they dynamically update the app in response to user actions.

flowchart LR
    btn["Button<br>id='btn2'"] -->|"n_clicks<br>Input"| update_counter(["update<br>callback"])
    update_counter -->|"children<br>Output"| counter["Paragraph<br>id='counter'"]
    style btn fill:#f9f,stroke:#333
    style counter fill:#bbf,stroke:#333
    style update_counter fill:#ff9,stroke:#333

In this example, the counter is incremented each time the button is pressed. The update_counter function encapsulates this logic and returns the result to be updated within the paragraph.

Congratulations, you just learned the most essential feature of Dash

Multi input callback

Now, let’s take it a step further. What if you want multiple components to control the same output? Dash makes this possible by supporting multiple inputs in a single callback.

Imagine you have two buttons: one adds 1 for each click, and the other subtracts 1 for each click.

Here’s how you can implement it:

from dash import Dash, html, callback, Input, Output, PreventUpdate

app = Dash(__name__)

# Declare the layout
app.layout = html.Div([
    html.P('Count: 0', id='counter'),
    html.Button('Click +', id='btn_add', n_clicks=0), 
    html.Button('Click -', id='btn_sub', n_clicks=0), # two buttons
])

# Define the callback
@app.callback(
    Output('counter', 'children'), 
    Input('btn_add', 'n_clicks'),
    Input('btn_sub', 'n_clicks') # now we have 2 inputs
)
def update_counter(n_clicks1, n_clicks2):
    return f"Count: {n_clicks1-n_clicks2}"

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

To do so, we simply added an extra Input in our @app.callback decorator. As a result, we now have 2 possible triggers:

flowchart LR
    btn1["Button<br>id='btn_add'"] -->|"n_clicks<br>Input"| update_counter(["update<br>callback"])
    btn2["Button<br>id='btn_sub'"] -->|"n_clicks<br>Input"| update_counter(["update<br>callback"])
    update_counter -->|"children<br>Output"| counter["Paragraph<br>id='counter'"]
    style btn1 fill:#f9f,stroke:#333
    style btn2 fill:#f9f,stroke:#333
    style counter fill:#bbf,stroke:#333
    style update_counter fill:#ff9,stroke:#333

In some cases, two inputs can be fired at the same time. Dash therefore handles it efficiently by triggering the callback only once. In our example, it means that the counters would update once even if the two buttons are clicked exactly at the same time.

Multiple inputs and outputs callbacks

The real excitement begins when we need to update multiple components simultaneously. For example, we can enhance the counter by displaying the result in red if it’s negative or green if it’s positive.

To achieve this, we update the style property of the component alongside its text. This involves adding another Output in our callback and adjusting the function accordingly:

@app.callback(
    Output('counter', 'children'), 
    Output('counter', 'style'),  # here we added property "style"
    Input('btn_add', 'n_clicks'),
    Input('btn_sub', 'n_clicks')
)
def update_counter(n_clicks1, n_clicks2):

    content = f"Count: {n_clicks1-n_clicks2}"

    if n_clicks1-n_clicks2 >= 0:
        style = {'color': 'green'}
    else:
        style = {'color': 'red'}

    return content, style  # as a result, we now return two values

Notice that now the function returns two variables: the content (for children property), and style (for style property).

If inputs can trigger a callback independantly or together, all outputs of a callback are always modified at the exact same time. It means that Dash will always update children and style, whenever the callback is triggered.

flowchart LR
    btn1["Button<br>id='btn_add'"] -->|"n_clicks<br>Input"| update_counter(["update<br>callback"])
    btn2["Button<br>id='btn_sub'"] -->|"n_clicks<br>Input"| update_counter(["update<br>callback"])
    update_counter -->|"children<br>Output"| counter["Paragraph<br>id='counter'"]
    update_counter -->|"style<br>Output"| counter["Paragraph<br>id='counter'"]
    style btn1 fill:#f9f,stroke:#333
    style btn2 fill:#f9f,stroke:#333
    style counter fill:#bbf,stroke:#333
    style update_counter fill:#ff9,stroke:#333

Good to know: it is still possible to not update an output by providing dash.no_output as value for an output.

Multiple callbacks with the same inputs

Dash does not limit the amount of callbacks attached to an input. However, it is theoretically forbidden to have more than one callback per output (= only one callback should be responsible for the update of a component’s property).

I wrote ‘theoretically‘ because it’s possible with the callback parameter allow_duplicate_output. However, you should avoid using it a much as possible as it makes a code more complicated to debug. See more here: https://dash.plotly.com/duplicate-callback-outputs

Let’s add a Progress bar to our counter. We need to update this progress bar every time that the buttons are clicked, hence a new update_pbar callback:

# Declare the layout
app.layout = html.Div([
    html.P('Count: 0', id='counter'),
    html.Progress(id="progress_bar", value=0, max=10), # We add the progress bar component
    html.Br(),
    html.Button('Click +', id='btn_add', n_clicks=0),
    html.Button('Click -', id='btn_sub', n_clicks=0),
])

# (... update counter)

@app.callback(
    Output('progress_bar', 'value'), 
    Input('btn_add', 'n_clicks'),
    Input('btn_sub', 'n_clicks')
)
def update_pbar(n_clicks1, n_clicks2):
    # This is a new callback that only updates the progress bar. 
    return n_clicks1-n_clicks2

As you can see, this callback is simple, only the output is different from the very first callback we implemented. The callback graph might now look like:

flowchart LR
    btn1["Button<br>id='btn_add'"] -->|"n_clicks<br>Input"| update_counter(["update_counter<br>callback"])
    btn2["Button<br>id='btn_sub'"] -->|"n_clicks<br>Input"| update_counter(["update_counter<br>callback"])
    update_counter -->|"children<br>Output"| counter["Paragraph<br>id='counter'"]
    update_counter -->|"style<br>Output"| counter["Paragraph<br>id='counter'"]
    
    btn1["Button<br>id='btn_add'"] -->|"n_clicks<br>Input"| update_pbar(["update_pbar<br>callback"])
    btn2["Button<br>id='btn_sub'"] -->|"n_clicks<br>Input"| update_pbar(["update_pbar<br>callback"])
    update_pbar -->|"value<br>Output"| pbar["Progress<br>id='progress_bar'"]
    
    style btn1 fill:#f9f,stroke:#333
    style btn2 fill:#f9f,stroke:#333
    style counter fill:#bbf,stroke:#333
    style pbar fill:#bbf,stroke:#333
    style update_counter fill:#ff9,stroke:#333
    style update_pbar fill:#ff9,stroke:#333

Note: In this example, we could have updated both the progress bar and the counter in one callback. Whether to group callbacks or keep them separate depends on your app’s needs. Take a look at this article: Dash Callbacks best practices.

Theorically, these two callbacks should run at the same time. In practice, dash will first trigger on callback and then the second, with no specific order. If you absolutely need one callback to be triggered before the other, then you can chain callbacks (as described in the next section).

True parallel processing is often more complex : it requires having to CPUs (or two servers) running the app. It depends on how the app is deployed, how the server handles the request, etc…. Most of the time, the callbacks are just run one after the other.

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!

Chained callbacks: callbacks triggering other callbacks

As your app grows, the logic for updating outputs may depend on multiple interconnected inputs. This is where chaining callbacks becomes an invaluable tool. By breaking down complex updates into smaller, linked callbacks, you can maintain a clear and scalable workflow.

Let’s now update our little app and show a multiplier slider. It will multiply the click count with the slider value :

# Declare the layout
app.layout = html.Div([
    html.P('Count: 0', id='counter'),
    html.Progress(id="progress_bar", value=0, max=50),
    html.Br(),
    html.Button('Click +', id='btn_add', n_clicks=0),
    html.Button('Click -', id='btn_sub', n_clicks=0),
    html.Br(),
    html.Label('Multiplier:'),
    dcc.Slider(id='multiplier', min=1, max=5, value=1, step=1)
], style={"max-width": "300px"})

@app.callback(
    Output('counter', 'children'), 
    Output('counter', 'style'), 
    Input('btn_add', 'n_clicks'),
    Input('btn_sub', 'n_clicks'),
    Input('multiplier', 'value')
)
def update_counter(n_clicks1, n_clicks2, multiplier):
    count = (n_clicks1 - n_clicks2) * multiplier
    content = f"Count: {count}"

    if count >= 0:
        style = {'color': 'green'}
    else:
        style = {'color': 'red'}

    return content, style

@app.callback(
    Output('progress_bar', 'value'), 
    Input('btn_add', 'n_clicks'),
    Input('btn_sub', 'n_clicks'),
    Input('multiplier', 'value')
)
def update_pbar(n_clicks1, n_clicks2, multiplier):
    return (n_clicks1 - n_clicks2) * multiplier

We now have 3 inputs. And this number will increase as the app gets more complex ; and it will get worse when adding more callbacks that use the count result.

A good solution would be to store this count result into memory using a dcc.Store component. The dcc.Store is a special Dash component that allows you to store data in the browser’s memory – think of it as a variable that persists between callbacks. It’s invisible to users but can hold any JSON-serializable data (numbers, strings, lists, or dictionaries). This component is particularly useful for:

• Sharing data between callbacks without passing it through visible components
• Reducing the number of redundant calculations
• Storing intermediate results that multiple callbacks need to access

Learn more about the dcc.Store component in the official documentation: https://dash.plotly.com/sharing-data-between-callbacks

Here’s how we can implement it:

app.layout = html.Div([
    dcc.Store(id='count_memory', data=0),  # Store component to save the count
    # ...
], style={"max-width": "300px"})

@app.callback(
    Output('count_memory', 'data'),  # Update the stored count
    Input('btn_add', 'n_clicks'),
    Input('btn_sub', 'n_clicks'),
    Input('multiplier', 'value'),
    State('count_memory', 'data')  # Access the current stored count
)
def update_store(n_clicks1, n_clicks2, multiplier, current_count):
    count = (n_clicks1 - n_clicks2) * multiplier
    return count

@app.callback(
    Output('counter', 'children'), 
    Output('counter', 'style'), 
    Input('count_memory', 'data')
)
def update_counter_display(count):
    content = f"Count: {count}"
    style = {'color': 'green'} if count >= 0 else {'color': 'red'}
    return content, style

@app.callback(
    Output('progress_bar', 'value'), 
    Input('count_memory', 'data')
)
def update_pbar(count):
    return count

We now have a callback responsible for the computation (update_store) and two callbacks responsible for display (update_counter_display and update_pbar). This gives the following diagram:

flowchart LR
    btn1["Button<br>id='btn_add'"] -->|"n_clicks<br>Input"| update_store(["update_store<br>callback"])
    btn2["Button<br>id='btn_sub'"] -->|"n_clicks<br>Input"| update_store
    multiplier["Input<br>id='multiplier'"] -->|"value<br>Input"| update_store
    store["Store<br>id='count_memory'"] -.->|"data<br>State"| update_store
    update_store -->|"data<br>Output"| store
    
    store -->|"data<br>Input"| update_counter(["update_counter<br>callback"])
    update_counter -->|"children<br>Output"| counter["Paragraph<br>id='counter'"]
    update_counter -->|"style<br>Output"| counter
    
    store -->|"data<br>Input"| update_pbar(["update_pbar<br>callback"])
    update_pbar -->|"value<br>Output"| pbar["Progress<br>id='progress_bar'"]

    style btn1 fill:#f9f,stroke:#333
    style btn2 fill:#f9f,stroke:#333
    style multiplier fill:#f9f,stroke:#333
    style counter fill:#bbf,stroke:#333
    style pbar fill:#bbf,stroke:#333
    style update_store fill:#ff9,stroke:#333
    style update_counter fill:#ff9,stroke:#333
    style update_pbar fill:#ff9,stroke:#333
    style store fill:#bbf,stroke:#333

Using State instead of Input

You’ll notice in our update_store callback that we use State('count_memory', 'data') instead of Input('count_memory', 'data'). This is because we want to access the current stored count but don’t want changes to it to trigger this callback. If we used Input, we’d create a circular dependency: the store update would trigger the callback, which would update the store, which would trigger the callback again!

Using State allows us to read the stored value only when we need it, while the actual triggers for our callback remain the button clicks and multiplier changes. This pattern of using State to access stored values is common when working with dcc.Store components – it gives you access to persistent data without creating unintended callback chains.

TL;DR. A State does not trigger a callback while an Input will. But both can be used to retrieve a component’s property.

Advantages and disadvantages of chaining callbacks

Chained callbacks help keep your code clean and logical. Instead of cramming everything into one big callback, you can break things down into smaller pieces that each do one job well. For example, one callback handles the data processing while another takes care of displaying it. This approach also opens up more interactive possibilities – when one callback’s output feeds into another’s input, you can create complex interactions like filters that update charts, which then update summary statistics.

But there are some pitfalls to be careful about. Debugging can get tricky when you have callback A triggering B, which triggers C and D, which then trigger even more callbacks… well, good luck figuring out where something went wrong!

You should also watch out for circular dependencies – that’s when your callbacks form a loop (A triggers B triggers C triggers A again). Dash will catch this and throw an error, but it’s a common gotcha when you’re building complex apps.

Want to learn more about avoiding circular dependencies? We have a full article here: How to avoid circular dependancies problem in Dash Plotly

Other types of callbacks

While we’ve covered the main callback patterns, Dash offers several specialized types of callbacks for specific use cases:

Background Callbacks

Background callbacks handle time-consuming operations without blocking your app’s responsiveness. They run intensive tasks in separate threads, making them perfect for heavy computations or long-running processes:

@app.callback(
    Output("results", "children"),
    Input("start", "n_clicks"),
    background=True
)
def slow_computation(n_clicks):
    # Your heavy computation here
    time.sleep(5)  # Simulating long task
    return "Done!"

Learn more in our guide: How to Use Background Callbacks in Dash Plotly

Clientside Callbacks

Clientside callbacks execute directly in the browser, eliminating server round-trips for faster performance. They’re ideal for simple UI updates and responsive interactions, but require JavaScript:

app.clientside_callback(
    """
    function(value) {
        return 'You typed: ' + value
    }
    """,
    Output('output-div', 'children'),
    Input('input-box', 'value')
)

Learn more: When to use clientside callbacks for Dash Plotly.

Pattern-Matching Callbacks

Pattern-matching callbacks enable handling dynamic sets of components through ID patterns. They’re particularly useful to attach callbacks to components that are created or removed at runtime:

@app.callback(
    Output({'type': 'dynamic-output', 'index': MATCH}, 'children'),
    Input({'type': 'dynamic-input', 'index': MATCH}, 'value')
)
def update_dynamic_output(value):
    return f"You entered: {value}"

Read the guide: How to use Pattern Matching Callbacks (Dash Plotly).

Conclusion

In this article, we explored the main types of Dash callbacks, from simple callbacks to multi-input, multi-output, and chained callbacks.

To deepen your understanding of Dash callbacks, you can:

• Read the official documentation on Dash callbacks: it’s dense, but there are much more detailed information than in this article (which was focused on giving simple examples).
• Play with the toy examples above: you could add more inputs, change the computation, add other types of components… be creative! It’s the best to learn.
• Go deeper with other types of callbacks: you now have the fundation for understand how callbacks triggered. Learn how to use background callbacks, clientside callbacks and patter-matching callbacks.

I hope you enjoyed this tutorial!

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 Tutorial: Dash callbacks (schemas & examples) est apparu en premier sur dash-resources.com.