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

Let’s go!

Dash-auth

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

pip install dash dash-auth

Then, create three files and one folder:

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

app.py

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

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

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

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

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

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

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

There are two key differences:

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

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

pages/public.py

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

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

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

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

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

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

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

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

pages/private.py

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

from dash import html, register_page
import flask

register_page(
    __name__,
    "/private",
)

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

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

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

Result

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

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

Conclusion

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

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

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

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

Happy Dash coding!

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

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

Let’s go!

Basic Dash auth

First, install Dash and Dash Auth:

pip install dash dash-auth

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

from dash import Dash, html
import dash_auth

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

# Create the Dash app
app = Dash(__name__)

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

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

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

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

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

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

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

And after log-in:

That’s it! You get a protected page.

There are some limitations:

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

Retrieve the user

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

# ...

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

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

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

Let’s explain this code:

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

Now let’s see the result:

Authentication function

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

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

Comparing hashed passwords

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

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

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

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

from werkzeug.security import check_password_hash

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

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

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

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

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

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

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

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

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

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

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

Much better!

Use a database

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

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

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

DB_PATH = "users.db"

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

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

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

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

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

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

DB_PATH = "users.db"

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

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

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

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

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

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

That’s it!

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

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

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

Why you can’t logout

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

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

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

Conclusion

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

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

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

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

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

I hope to see you there!

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

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

Let’s dive in!

First, what is allow_duplicate=True?

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

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

Here is an example:

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

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

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

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

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

Pros and cons of allow_duplicate=True

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

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

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

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

Harder to track logic & Maintainability Concerns

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

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

Potential race conditions

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

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

Good use example 1: separate concern

Let’s take an example of fully separated logic.

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

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

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

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

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

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

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

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

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

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

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

Good use example 2: partial update

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

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

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

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

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

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

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

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

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

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

Bad use example 1: harder to track

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

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

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

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

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

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

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

Bad example 2: race condition

This example will illustrate the race condition problem.

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

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

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

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

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

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

Let’s give an example:

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

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

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

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

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

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

In this case, a better solution would have been to

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

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

Conclusion

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

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

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

— Happy coding!

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

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

Let’s dive in

The problem

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

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

The code would be something like:

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

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

    raise PreventUpdate

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

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

    raise PreventUpdate

# ... other callbacks

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

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

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

You can try it below (or click here):

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

Why this problem appears.

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

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

Here is a video example with 4 inputs:

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

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

But let’s see why.

Solution 1: chaining callbacks

How do we make callbacks sequential?

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

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

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

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

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

    raise PreventUpdate

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

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

    raise PreventUpdate

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

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

Solution 2: rewriting callbacks

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

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

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

    return user_data

And that solves the synchronization problem.

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

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

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


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

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

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

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

    # .. other possible inputs being hanled

    return user_data

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

Solution 3: using intermediary stores

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

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

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

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

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

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

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

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

# ... other callbacks 

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

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

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

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

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

Solution 4: using Partial Update

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

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

Let’s see the code:

from dash import Patch

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

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

    raise PreventUpdate

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

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

    raise PreventUpdate

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

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

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

Conclusion

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

But here key takeaways:

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

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

Happy coding!

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

You will find in this article a short description of both frameworks and two code examples of use cases that suit the former and the latter. At the end, we summarize the comparison for Dash vs. Streamlit in comprehensive tables. Let’s dive in!

TL;DR: Streamlit is very good for building tools, Dash is very good for building apps.

About Streamlit

Streamlit, is designed for creating data apps with minimal effort, focusing on simplicity and fast development cycles. Its key strengths are:

• Fast prototyping of data applications
• Simple, declarative syntax that follows a linear execution flow
• Built-in widgets and layout components
• Automatic reactivity – the entire app reruns on any user interaction
• Effortless deployment through Streamlit Cloud

Example: Streamlit is an excellent choice if you want to quickly transform a Jupyter notebook into an interactive web application or create internal tools for data exploration without spending time on frontend development.

Streamlit has grown significantly in popularity due to its simplicity and ease of use. It’s worth mentioning that deploying a Streamlit app and making it accessible on the internet is super easy with Streamlit Cloud (just a few clicks).

About Dash

Dash Plotly, on the other hand, is specifically designed for building analytical web applications and data visualization dashboards. Its key strengths are:

• Creating interactive web applications 100% in Python
• Real-time data updates and callbacks
• Deep integration with Plotly’s visualization library
• Building data-heavy applications for data scientists and analysts
• Highly customizable layouts and components

Example: Dash is an excellent choice if want to build a data web application that requires complex interactions between components or if you need pixel-perfect control over your visualizations, such as financial analytics platforms or enterprise-grade dashboards.

Dash is a growing framework with a vibrant community. Recent updates have expanded Dash beyond just data visualization, moving towards becoming a more complete Python web framework with features like built-in URL routing, authentication, and advanced component libraries. This evolution makes Dash increasingly suitable for building full-featured web applications entirely in Python.

Code comparison

I assume that if you read this, you are somehow familiar with Python . So let’s take a look at some tangible examples, with code. That will be much more illustrative.

Where Streamlit is better

Streamlit truly shines in its simplicity and speed of development. Here’s how easy it is to create a simple data app:

###### STREAMLIT EXAMPLE ######
import streamlit as st
import pandas as pd
import plotly.express as px

st.title("Simple Data Explorer")

# Load data
uploaded_file = st.file_uploader("Upload CSV", type=['csv'])
if uploaded_file:
    df = pd.read_csv(uploaded_file)

# Simple controls
    x_column = st.selectbox("X axis", df.columns)
    y_column = st.selectbox("Y axis", df.columns)

# Create and display plot
    fig = px.scatter(df, x=x_column, y=y_column)
    st.plotly_chart(fig)

# Show data summary
    st.write("Data Summary:", df.describe())


# If you want to run this example, open the terminal and:
# pip install streamlit pandas plotly
# streamlit run streamlit_app.py

This concise code creates a complete app with file uploading, interactive controls, visualization, and data summary:

To be honest, how straightforward and readable is this code is blows my mind . That’s difficult to do simpler, well done Streamlit!

Each line does exactly one thing: getting data from the user (reading the file, or the dropdown input) or udpating a visual (chart or table). One thing is handled by one function, keeping things clear and easy to understand.

Now let’s see the equivalent in Dash:

###### DASH EQUIVALENT ######
import io
import pandas as pd
import plotly.express as px
import base64
import dash_bootstrap_components as dbc
from dash import Dash, dcc, html, Input, Output, State, no_update

app = Dash(
    __name__, 
    external_stylesheets=[dbc.themes.BOOTSTRAP], 
    suppress_callback_exceptions=True
)

# Custom CSS for the upload component
upload_style = {
    'width': '100%',
    'height': '60px',
    'lineHeight': '60px',
    'borderWidth': '1px',
    'borderStyle': 'dashed',
    'borderRadius': '5px',
    'textAlign': 'center',
    'margin': '10px 0',
    'backgroundColor': '#fafafa',
    'cursor': 'pointer',
    'transition': 'border .24s ease-in-out',
}

# Define the full layout upfront
app.layout = dbc.Container([
    html.H1("Simple Data Explorer", className="text-center my-4"),

    # Upload component
    dcc.Upload(
        id='upload-data',
        children=html.Div([
            'Drag and Drop or ',
            html.A('Select CSV', className="text-primary")
        ]),
        style=upload_style,
        multiple=False
    ),

    # Store for the dataframe
    dcc.Store(id='dataframe', storage_type='memory'),

    # Analysis section (hidden by default)
    dbc.Container([
        dbc.Row([
            dbc.Col([
                html.Label("X axis:", className="mt-3"),
                dcc.Dropdown(id='x-column', options=[], value=None),
                html.Label("Y axis:", className="mt-3"),
                dcc.Dropdown(id='y-column', options=[], value=None),
            ], width=12)
        ]),

        html.Div(id='graph-container', className="my-4"),

        html.H3("Data Summary", className="mt-4"),
        html.Div(id='data-summary')
    ], id='analysis-container', style={'display': 'none'})

], fluid=False, style={'maxWidth': '800px'})

@app.callback(
    [Output('dataframe', 'data'),
     Output('analysis-container', 'style'),
     Output('x-column', 'options'),
     Output('y-column', 'options')],
    Input('upload-data', 'contents'),
    State('upload-data', 'filename')
)
def process_upload(contents, filename):
    if contents is None:
        return None, {'display': 'none'}, [], []

    # Decode the base64 encoded content
    content_type, content_string = contents.split(',')
    decoded = base64.b64decode(content_string)

    try:
        # Read the CSV file
        df = pd.read_csv(io.StringIO(decoded.decode('utf-8')), sep=";")
        options = [{'label': i, 'value': i} for i in df.columns]
        return (
            df.to_json(),
            {'display': 'block'},
            options,
            options
        )
    except Exception as e:
        return None, {'display': 'none'}, [], []

@app.callback(
    Output('data-summary', 'children'),
    Input('dataframe', 'data')
)
def update_summary(json_data):
    if not json_data:
        return no_update
    
    df = pd.read_json(json_data)
    return dbc.Table.from_dataframe(
        df.describe().reset_index(),
        striped=True,
        bordered=True,
        hover=True,
        responsive=True
    )

@app.callback(
    Output('graph-container', 'children'),
    [Input('x-column', 'value'),
     Input('y-column', 'value'),
     Input('dataframe', 'data')]
)
def update_graph(x_col, y_col, json_data):
    if not json_data or not x_col or not y_col:
        return html.Div("Please select X and Y columns")

    df = pd.read_json(json_data)
    fig = px.scatter(df, x=x_col, y=y_col)
    return dcc.Graph(figure=fig)

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

# If you want to run the app, do:
# pip install dash dash-bootstrap-components pandas plotly
# python dash_app.py

Which is giving the following app:

As you can see, the Dash implementation requires way more code, and more complex code. Why such a difference ?

In Dash, the components are not ‘alive’ by themselves, meaning you need to create explicit callbacks with inputs and outputs to create interactivity —which Streamlit provides automatically:

• Instead of using st.file_uploader, we need to handle the upload of the file in a callback by reading the base64 content ;
• Instead of waiting for x_column and y_column to be filled and create the graph, we need to create a callback that will use them as input and create a graph as an output;

Also, styling the Dash app requires a little more effort than with Streamlit. Which can be both a good thing and a bad thing, as we’ll see later.

Where Dash is better

While Streamlit excels in simplicity, Dash is better in customizability and scalability. Let’s see why.

Customization.

Dash is much more customizable and scalable because you can fully customize how the page looks, create multi-page apps effortlessly, and specify precisely how each component interacts.

Here’s an example of what’s possible with Dash:

The Materials Explorer project is one of the most interesting publicly available Dash app, in my opinion. It features custom layouts, menus, popups, sidebar, visualizations and multiple pages. I encourage you to pause reading this article and explore it (but come back after!).

You can find many more examples of sophisticated Dash applications in this gallery and on the examples page:

Looking at the Streamlit gallery, you’ll notice that despite the variety of applications, they all follow the same visual structure and design patterns:

If it is possible to change a few colors, Streamlit is simply not made for high customization.

Scalability.

If your app grows, you might need more components and more interactions between them. With Dash, you can scale easily to hundreds of components and callbacks to handle interactions. Dash callbacks only update what’s necessary, providing better performance for complex applications.

Streamlit is not made the same way. When a user changes anything in Streamlit, the entire app runs again from top to bottom: a component changing at the very bottom of your app will trigger a full reload of other components, full reload of data, etc. This means developers must implement optimizations (e.g., using @st.cache_data) or the app will run slowly very quickly as it grows.

Dash plotly vs. Streamlit: table comparison

We compared each framework feature regarding how it is either built-in (), possible with extension (—), or needs to be implemented manually ().

Web Application Features

Feature	Dash	Streamlit	Notes
Routing			Dash has built-in routing; Streamlit provides st.pages
Custom Components			Both support custom components
Authentication	—	—	Both require extensions
Layout Flexibility			Dash offers more granular control, Streamlit follows a strict top-down layout
Mobile Responsiveness	—		Streamlit is responsive by default, while it’s up to you to make it with Dash.

For web application features, Dash provides more built-in capabilities with flexible layouts, custom components, and mobile support. While both frameworks handle routing and require authentication extensions, Streamlit’s simpler structure makes it less adaptable for complex web applications requiring custom layouts.

Data Visualization & Interactivity

Feature	Dash	Streamlit	Notes
Interactive Graphs			Both excellent but different approaches
Real-time Updates			Streamlit reruns entire script
Callback System			Dash’s core feature vs. Streamlit’s reactivity
Component State			Dash: per-component; Streamlit: session state
Custom Visualizations		—	Dash offers more customization
Widget Variety			Both offer rich UI elements, but Streamlit offer more easy to use components like st.file_uploader

Both frameworks excel at data visualization, but their approaches differ significantly. Dash offers more precise control over interactions through its callback system, while Streamlit provides automatic reactivity at the cost of running the entire script on each interaction.

Development & Deployment

Feature	Dash	Streamlit	Notes
Learning Curve	—		Streamlit is easier to learn
Development Speed	—		Streamlit enables faster prototyping
Testing		—	Dash has better testing infrastructure
Deployment Options			Both have cloud options, but Streamlit made it really easy.
Performance		—	Dash scales better for complex apps
Community & Resources			Both have active communities
Integration with Data Science			Streamlit workflow is more notebook-like

Streamlit is the clear winner for development speed and ease of use, making it perfect for rapid prototyping. Dash, however, offers better performance for complex applications and scales better for production use.

My personal opinion

Even if you are on “dash-resources.com“, I really tried to be as neutral as possible for this article. But you might guess that I might be biaised , so here is my full opinion on this comparison.

I found that both Streamlit and Dash required similar time investment to learn the basic concepts and components. Learning the Dash API (dcc.Upload, dcc.Button, dcc.Input, …) will asked me the same effort as learning the Streamlit API (st.file_uploader, st.button, st.text_input, st.selectbox, st.slider, …). Dash callbacks are quite easy to create.

However, I quickly felt limitated with Streamlit in the way that I could customize my app interactions and layout. Dash has proven to be significantly more flexible in the long run (my SaaS is still running on Dash…).

That being said, I understand why some developers prefer Streamlit, particularly for specific use cases like ML model training and inference interfaces, where they want something that feels like a Jupyter notebook but with a user interface. For these focused applications where extensive customization isn’t needed, Streamlit’s notebook-like approach can be a good fit.

I think Streamlit is very good to build tools, and Dash is very good to build apps.

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!

Conclusion

As you now understand, the difference between these two Python frameworks isn’t about their capability — they both provide the ability to develop data science oriented applications. It is more about what you want your app to look like at the end.

At the end, the choice depends on 1) the type of data app you need to build and 2) your skill set and workflow preferences:

• Choose Streamlit if you need to build a streamlined app interface quickly. It’s perfect for people that work with notebooks and want to keep that workflow and feeling. Streamlit’s simplicity makes it ideal for data scientists who want to share their work without learning web development.
• Choose Dash if you want to create dashboards with no limits in terms of display and features. It’s perfect for people that want to build scalable apps (that can grow in time in terms of features) and SaaS data applications. Dash’s component-based architecture and callback system provide the flexibility needed for enterprise-grade applications.

I hope this article helped you better understand the differences between Dash and Streamlit!

If you want to learn more about Dash plotly, you’re in the right place! We have a course and a lot of articles with examples and practical solutions. Hope to see you there

L’article Dash plotly vs. Streamlit: what are the differences? est apparu en premier sur dash-resources.com.

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

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

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

A bit of history

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

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

Introduction to dcc.Store

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

It has four key properties:

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

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

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

app = Dash(__name__)

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

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

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

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

Why it is needed

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

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

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

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

Understanding dcc.Store Storage Types

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

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

Each storage type serves different purposes:

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

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

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

How much can you store?

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

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

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

How to debug dcc.Store

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

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

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

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

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

A few important notes:

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

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

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

Some best practices for dcc.Store

Serialize data properly

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

TypeError: Object of type DataFrame is not JSON serializable.

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

Don’t store large objects or DataFrames

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

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

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

Use the right storage type

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

Trigger callbacks efficiently

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

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

Conclusion

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

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

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

Happy coding !

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

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

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

Context

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

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

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

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

So how to debug this?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Resolution

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

callback 1 – before

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

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

callback 1 – after (removed useless state!)

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

Now, looking at the second callback.

callback 2 – before

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

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

callback 2 – after (changed to modified_timestamp)

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

And that did the job perfectly!

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

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

Result

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

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

Conclusion

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

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

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

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

Happy coding!

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

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

Introduction

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

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

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

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

Pick a font

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

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

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

Recommended fonts are the basic ones:

• Arial, Open Sans, Verdana, Helvetica Neue.

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

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

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

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

Pick colors correctly

No colors is terrible

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

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

Too many colors is terrible

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

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

Importance of color choice

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

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

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

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

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

Beware of the hierarchy

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

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

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

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

Space things out!

Let your components breathe:

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

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

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

Keep things homogeneous

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

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

But what does this mean in practice?

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

Small details make a big difference!

Remember to style charts too

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

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

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

Use pre-made components

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

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

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

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

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

See also:

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

Conclusion

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

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

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

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

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

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

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

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

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

The animate and animation_options parameters in Dash’s Graph component control how your visualizations transition between updates. These parameters are essential for creating smooth, interactive data visualizations that respond to user input or real-time data updates.

How do animations work?

When enabled, animations create smooth transitions between graph updates instead of abrupt changes. This includes transitions for data points, axes ranges, and other visual elements. The animations can be customized using animation_options to control timing, easing, and transition modes.

Official Documentation

From the documentation:

animate (boolean; default False): Beta: If True, animate between updates using plotly.js’s animate function.

animation_options (dict; default { frame: { redraw: False, }, transition: { duration: 750, ease: 'cubic-in-out', },}): Beta: Object containing animation settings. Only applies if animate is True.

Parameter Values:

animate

1. True: Enables automatic animations for all updates
2. False (default): Disables animations

animate_options

The animate_options dictionary can include:

{
    'frame': {
        'redraw': True    # Whether to redraw the entire graph
    },
    'transition': {
        'duration': 500,  # Duration of transition between frames
        'easing': 'cubic-in-out'  # Easing function to use
    },
    'mode': 'immediate'  # Animation mode
}

The documentation do not say exactly what redraw does. As its impact is unclear, we recommend keeping it to True.

Defining redraw: Setting redraw: false is an optimization for scatter plots so that animate just makes changes without redrawing the whole plot. For other plot types, such as contour plots, every frame must be a total plot redraw, i.e. redraw: true.

Good to know: under the hood, the plotly charting library is handling animations. You will therefore find more information on this page: https://plotly.com/python/animations/.

Code Examples and Use Cases

1. Basic Animation (animate=True)

Use this for simple animations with default settings:

html.Div([
    dcc.Graph(
        animate=True,
        figure=base_figure,
        style={'height': '100%'}
    )
], style={
    'width': '100%',
    'height': '400px',
    'border': '1px solid #ddd',
    'padding': '10px'
})

2. Customized Animation with Options

Use this when you need precise control over animation timing and behavior:

# Example of linear, 2s animation
html.Div([
    dcc.Graph(
        figure=fig
        animate=True,
        animation_options={
            'transition': {
                'duration': 500,
                'easing': 'linear'
            }
        },
    )
])

The easing parameter will accept all following values (source):

"linear" | "quad" | "cubic" | "sin" | "exp" | "circle" | "elastic" | "back" | "bounce" | "linear-in" | "quad-in" | "cubic-in" | "sin-in" | "exp-in" | "circle-in" | "elastic-in" | "back-in" | "bounce-in" | "linear-out" | "quad-out" | "cubic-out" | "sin-out" | "exp-out" | "circle-out" | "elastic-out" | "back-out" | "bounce-out" | "linear-in-out" | "quad-in-out" | "cubic-in-out" | "sin-in-out" | "exp-in-out" | "circle-in-out" | "elastic-in-out" | "back-in-out" | "bounce-in-out"

Best Practices & Tips

• Keep transitions under 1000ms for optimal user experience (150-300ms are good!).
• Remember to update the figure layout (x_min, x_max, …) if you add new points or modify data, otherwise it might not become visible.

L’article How to animate Dash Graphs est apparu en premier sur dash-resources.com.

How works the responsive parameter?

The responsive parameter in Dash’s Graph component controls how your graph responds to window resizing and container element changes. This is crucial for creating graphs that work well across different screen sizes and layouts.

Official documentation

From the documentation:

responsive (a value equal to: true, false or ‘auto’; default 'auto'): If True, the Plotly.js plot will be fully responsive to window resize and parent element resize event. This is achieved by overriding config.responsive to True, figure.layout.autosize to True and unsetting figure.layout.height and figure.layout.width. If False, the Plotly.js plot not be responsive to window resize and parent element resize event. This is achieved by overriding config.responsive to False and figure.layout.autosize to False. If ‘auto’ (default), the Graph will determine if the Plotly.js plot can be made fully responsive (True) or not (False) based on the values in config.responsive, figure.layout.autosize, figure.layout.height, figure.layout.width. This is the legacy behavior of the Graph component. Needs to be combined with appropriate dimension / styling through the style prop to fully take effect.

Parameter Values:

1. True: Forces the graph to be fully responsive
2. False: Disables responsiveness
3. 'auto' (default): Determines responsiveness based on other settings

Code Examples and Use Cases

1. Fully Responsive Graph (responsive=True)

Use this when you want your graph to always adapt to its container size, horizontally and vertically:

# Container with fluid width
html.Div([ 
      dcc.Graph(
          responsive=True,
          figure=base_figure, 
          style={'height': '100%'}  # Necessary to adapt vertically
      )
  ], style={
      'width': '100%',  # Fluid width
      'height': '400px',
      'border': '2px solid #2196F3',
      'padding': '10px',
      'margin': '10px 0'
  })

In most cases, the container should have a fixed height to make this work. You can however make the container height 100% of its own height using CSS flexbox.

2. Non-Responsive Graph (responsive=False)

Use this when you need fixed dimensions regardless of screen size:

# Container with fixed width
html.Div([
    dcc.Graph(
        responsive=False,
        figure={
            'data': fig['data'],
            'layout': {
                'width': 500,  # Fixed width
                'height': 300  # Fixed height
            }
        }
    )
], style={
    'width': '800px',
    'height': '400px',
    'border': '2px solid #4CAF50',
    'padding': '10px'
})

Note that in this case, the graph will take the default dimensions in the figure layout. The container should have greater width and heights than the figure, or the graph will overflow.

Setting CSS style with width and height properties on the graph will have the negative effect of making the container believe that your graph is smaller or larger than what it is really.

3. Auto-Responsive Graph (responsive=’auto’)

Use this default setting when you want the graph to determine responsiveness based on its layout settings:

# Container with max-width constraint
html.Div([
    dcc.Graph(
        responsive='auto',
        figure={
            'data': fig['data'],
            'layout': {
                'title': 'Auto-Responsive Graph',
                'autosize': True,
                'height': 350  # Fixed height only
            }
        }
    )
], style={
    'width': '100%',
    'height': '400px',
    'border': '2px solid #FF9800',
    'padding': '10px'
})

In this example, the graph is horizontally responsive but not vertically responsive as its height is fixed in the figure layout.

The ‘auto’ setting essentially lets you have fine-grained control over what aspects of your graph should be responsive while preserving other dimensional constraints you’ve set. Using responsive=True or False is often clearer.

4. Responsive with Constraints

Use this when you want responsiveness within certain bounds:

# Container with min/max constraints
html.Div([
    dcc.Graph(
        responsive=True,
        figure=fig
    )
], style={
    'width': '100%',
    'minWidth': '200px',
    'maxWidth': '500px',
    'height': '400px',
    'border': '2px solid #E91E63',
    'padding': '10px'
})

This case differs from the first one in the sense that 1) the graph height is not fluid and 2) there are maximum and minimum width specified on the container.

Best practices & tips

• If you want the graph to have the same height as the container: always explicit the container’s height, otherwise setting height: 100% on the graph will not work.
• To simplify things, keep the graph has the only child of your container.
• Add padding to prevent graph from touching container edges, use the CSS overflow if you need to hide the overflowing content or make scrollable container.
• Use percentage widths for fluid layouts, combined with CSS properties like max-width and max-height.

L’article How to make responsive Dash Graphs est apparu en premier sur dash-resources.com.