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.

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 tutorial, I’ll give you tips and advices to keep in mind to create visually appealing dashboards and Dash apps, to increase the usability and aesthetics of your project.

Introduction

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

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

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

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

Pick a font

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

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

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

Recommended fonts are the basic ones:

• Arial, Open Sans, Verdana, Helvetica Neue.

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

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

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

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

Pick colors correctly

No colors is terrible

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

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

Too many colors is terrible

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

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

Importance of color choice

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

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

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

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

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

Beware of the hierarchy

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

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

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

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

Space things out!

Let your components breathe:

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

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

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

Keep things homogeneous

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

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

But what does this mean in practice?

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

Small details make a big difference!

Remember to style charts too

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

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

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

Use pre-made components

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

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

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

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

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

See also:

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

Conclusion

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

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

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

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

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

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

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

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

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

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

Let’s get started!

Prerequisites

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

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

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

Step 1: Setting up the Environment

First, let’s install the packages using pip:

pip install dash dash-chat openai

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

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

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

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

Step 2: Creating the application layout

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

app = dash.Dash(__name__)

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

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

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

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

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

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

Step 3: Implementing the chat callback

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

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

Here’s how it works:

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

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

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

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

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

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

Straightforward and simple

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

Step 4: Running the app

We finally add the code to run our server:

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

Here is the result:

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

Full code

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

Going further

Here are a few ideas to improve this chat app:

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

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

Conclusion

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

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

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

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

Happy coding!

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

There are three main approaches to display tables, each with its own strengths:

1. dbc.Table.from_dataframe: A simple, static table from Dash Bootstrap Components.
2. dash_table.DataTable: The built-in interactive table component by Plotly.
3. dash-ag-grid: A powerful wrapper around AG Grid for advanced functionality.

Let’s dive in!

1. Quick Start: The Bootstrap Table Approach

The simplest way to display a DataFrame as a table is by using Dash Bootstrap Components‘ Table.from_dataframe function. It offers a clean, professional appearance with responsive design and basic styling options like striped rows, borders, and hover effects.

It requires to install the community package:

pip install dash-bootstrap-components

Here is a an example code loading the titanic dataset and displaying it:

import dash
from dash import html
import dash_bootstrap_components as dbc
import pandas as pd

# Load Titanic dataset and select subset of columns for clarity
url = "https://raw.githubusercontent.com/datasciencedojo/datasets/master/titanic.csv"
df = pd.read_csv(url)
df = df[['PassengerId', 'Survived', 'Pclass', 'Name', 'Sex', 'Age', 'Fare']]

# Modify columns for better readability
df['Survived'] = df['Survived'].map({0: '', 1: ''})
df['Fare'] = df['Fare'].map(lambda x: f"${x:.2f}")

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

# Generate the table using dbc.Table.from_dataframe
table = dbc.Table.from_dataframe(
    df,
    # Key styling options:
    striped=True,
    bordered=True,
    hover=True,
)

# Define the app layout
app.layout = html.Div([table])

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

Try it below (or click here):

As you can see, we get a pretty decent table for consulting data. But Bootstrap tables are static: you cannot filter rows or sort column values. Other advanced features like pagination or cell editing (that come built-in with DataTable or AG Grid) are nonexistent, and implementing these would require significant development effort.

However, the Bootstrap table makes it easy to embed any Dash element inside each cell, giving you complete control over the content (e.g. adding a button or link or image in a cell is as simple as for anywhere in your dash app layout).

Note: under the hood, dbc.Table.from_dataframe is just building a table as we could do we html.Table, html.Tr, html.Td. It’s just an easier way to produce the tanle from a DataFrame plus having a good styling by default.

Styling with dbc.Table

It is easy to use CSS to style Dash Bootstrap tables. It is also possible to modify the table created to add styles to each cell, or each row.

# Modify the 'Survived' cells to apply conditional styling
for i, tr in enumerate(table.children[1].children):  # Iterate over rows (tbody > tr)
    for td in tr.children:  # Iterate over cells (td)
        if df.iloc[i]['Survived'] == '':
            td.style = {'color': 'red'}

This way, we can easily implement our own styling rules on the generated table, without having to know extensive parameters (which you’ll see, is not the case for DataTable and AG Grid).

Why choose Bootstrap Table?

You should start with a Dash Bootstrap table when your data does not require filtering or sorting features, and if you plan to display a small dataset (i.e. < 100 rows).

It’s also maybe the easiest choice if you plan to mix the table content with other Dash components (checkboxes, dropdowns, buttons, etc.).

2. Interactive Tables with Dash DataTable

When you need interactivity, Dash’s built-in DataTable provides an excellent middle ground.

It comes included with the dash package and offers many features that work out-of-the-box, including editing cells, sorting, filtering, pagination, and column resizing.

from dash import Dash, dash_table
import pandas as pd

app = Dash(__name__)

# Load Titanic dataset and select subset of columns for clarity
url = "https://raw.githubusercontent.com/datasciencedojo/datasets/master/titanic.csv"
df = pd.read_csv(url)
df = df[['PassengerId', 'Survived', 'Pclass', 'Name', 'Sex', 'Age', 'Fare']]

# Modify columns for better readability
# Notice that Fare is formatted inside the DataTable component
df['Survived'] = df['Survived'].map({0: '', 1: ''})

# Create the DataTable
app.layout = dash_table.DataTable(
    data=df.to_dict('records'),

    # Note: columns parameter is mandatory
    columns=[
        {'name': 'Passenger ID', 'id': 'PassengerId', 'type': 'numeric', 'selectable': True, 'clearable': True, 'editable': True},
        {'name': 'Survived', 'id': 'Survived', 'type': 'numeric'},
        {'name': 'Class', 'id': 'Pclass', 'type': 'numeric'},
        {'name': 'Name', 'id': 'Name', 'type': 'text'},
        {'name': 'Sex', 'id': 'Sex', 'type': 'text'},
        {'name': 'Age', 'id': 'Age', 'type': 'numeric'},
        {'name': 'Fare', 'id': 'Fare', 'type': 'numeric', 'format': {'specifier': '$.2f'}},
    ],
    
    # Enable key features
    editable=True,
    sort_action='native',
    filter_action='native',
    row_selectable="multi",
    row_deletable=True,
    page_size=15,

    # Additional styling
    style_cell={
        'fontFamily': 'Arial',
        'padding': '5px 10px'
    },
    style_header={
        'backgroundColor': 'rgb(230, 230, 230)',
        'fontWeight': 'bold'
    },
)

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

Try to filter and /or order rows below (or click here):

DataTable provides sorting and filtering capabilities out-of-the-box, either on the client-side (handled by the browser) or the backend (using python, with a callback). These features make it easy to visualize and manage a lot of data.

Note: Using backend pagination and filtering can be particularly advantageous for large datasets. Instead of loading the entire dataset at once, only the required chunks of data are retrieved and processed on the server as needed. This approach reduces load times, minimizes bandwidth usage, and significantly improves performance for end users. A similar approach is Virtual Scrolling (or Infinite Scrolling).

DataTable also provides editing out-of-the-box, which is not available with Bootstrap tables (unless you handle it yourself). Users can modify the cell content, which can trigger callbacks to update your underlying data.

While DataTable doesn’t support other Dash components inside cells, it does offer alternatives: you can use markdown for basic styling (bold, italic, …) and create clickable links. There also are some parameters you can use for display tooltips and embed dropdowns. But the content you can embed is limited compared to the Dash Bootstrap table.

Styling with DataTable

Dash DataTable allows for extensive styling through properties like style_header, style_data and and style_cell. Conditional formatting lets you dynamically style cells or rows based on data values:

    # Style rows based on data
    style_data_conditional=[
        {
            'if': {'filter_query': '{Survived} = ""'},
            'color': 'red'
        },
        {
            'if': {'row_index': 'odd'},
            'backgroundColor': 'rgb(220, 220, 220)',
        }
    ],

The difference is that styling or formatting is done using datatable parameters. Why? Because the datatable must separate the model (data representation) from the view (how it is displayed) to ensure filtering and sorting capabilities (look at how Fare is formatted in the example).

Why choose dataTable?

Go for a DataTable if you need an interactive table, for a few or for many rows. The built-in sorting, filtering, and pagination work seamlessly with backend data processing, making it efficient as well for large datasets.

If you need a table that feels like a spreadsheet but don’t require the full complexity of AG Grid, DataTable is often the right choice.

3. Advanced tables with Dash AG Grid

Dash AG Grid is a wrapper around AG Grid, a dedicated library for displaying tables.

As a result, AG Grid offers the most comprehensive feature set, bringing an Excel-like experience to your web application. While it shares many features with DataTable, it excels in advanced functionality like row grouping, pivoting, and tree data structures.

Important note: AG Grid requires an enterprise license to access its most advanced features, such as pivoting, advanced filtering, and enterprise-ready exporting options. However, the main features are accessible in the free, community version.

import dash
from dash import html
import dash_ag_grid as dag
import pandas as pd

app = dash.Dash(__name__)

# Load Titanic dataset and select subset of columns for clarity
url = "https://raw.githubusercontent.com/datasciencedojo/datasets/master/titanic.csv"
df = pd.read_csv(url)
df = df[['PassengerId', 'Survived', 'Pclass', 'Name', 'Sex', 'Age', 'Fare']]

# Modify columns for better readability
df['Survived'] = df['Survived'].map({0: '', 1: ''})

columnDefs = [
    {
        'field': 'PassengerId',
        'headerName': 'Passenger ID',
        # Add a checkbox on this column
        'checkboxSelection': True
    },
    {
        'field': 'Survived',
        'width': 100,
    },
    {
        'field': 'Pclass',
        'headerName': 'Class',
        'width': 90
    },
    {
        'field': 'Name',
        'width': 300
    },
    {
        'field': 'Sex',
        'width': 90
    },
    {
        'field': 'Age',
        'width': 90
    },
    {
        'field': 'Fare',
        'width': 100,
        # The formatting requires a JavaScript function to be passed as a string
        'valueFormatter': {'function': 'd3.format("$.2f")(params.value)'}
    },
]

# Create AG Grid component
app.layout = html.Div([
    dag.AgGrid(
        rowData=df.to_dict('records'),
        columnDefs=columnDefs,

        # Enable key features
        defaultColDef={
            'editable': True,
            'resizable': True,
            'sortable': True,
            'filter': True
        },
        dashGridOptions={
            'pagination': True,
            'paginationAutoPageSize': True,
            'animateRows': True,
            'enableRangeSelection': True
        },

        style={"height": "100vh"}  # Take 100% of window height
    )
])

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

Try it below (or click here):

As you can see, the AG Grid table comes with a clean, modern user interface and user experience (UI/UX). Editable cells, pagination, filtering, ordering, infinite scrolling are supported out-of-the-box. It also comes with powerful features like row selection, cell pinning, and row dragging. You can even create advanced layouts like row trees or enable dragging rows between tables.

However, advanced layout customization comes at the price of complexity. For example, embedding a button in an AG Grid table is possible but will be a little more complicated than with the Bootstrap option. For instance, AG Grid supports custom components, but implementing them requires knowledge of JavaScript/React.

Note: I could not summerize here all the tabular use cases made possible with AG Grid. I encourage you to visit the extensive Dash AG Grid documentation and examples, it’s really interesting.

Styling with AG Grid

AG Grid is really flexible, but the configuration for styling can take some time compared to the other options. You can apply conditional styling to cells, rows, or columns, and even use custom renderers for advanced visual customizations:

getRowStyle = {
    "styleConditions": [
        {
            "condition": "params.data.Survived === ''",
            "style": {"color": "red"},
        },
    ],
}

You will notice the subtle difference: the condition code is now written in JavaScript, not Python. Which makes things a little more complex if you don’t know the very basics of this language.

Why choose AG Grid?

AG Grid is the best choice when you’re building enterprise-level applications or need to replicate desktop spreadsheet functionality in the browser. It’s particularly valuable when your users are coming from Excel backgrounds and expect similar functionality in your web application.

In short, choose AG Grid when you need to provide the best user experience on your data table. But be prepared to spend more time tweaking the parameters of AG Grid.

4. Not recommended approaches

There are two approaches that, while possible, are generally not recommended:

1. Using HTML Table Components (html.Table, html.Td, html.Tr): While this gives you full control over the HTML, you’ll need to implement all functionality from scratch, making it tedious and time-consuming. This is essentially what Dash Bootstrap does under the hood.
2. Using Plotly Graph Objects Table (go.Table): This is designed for displaying tables within chart contexts and lacks the flexibility and features of the dedicated table components discussed above.

5. Feature comparison: (bootstrap) Table vs DataTable vs AG Grid

Now that we have reviewed the basic features, let’s summarize them in a detailed table:

Feature	Bootstrap Table	DataTable	AG Grid
Basic Display
Custom Components in Cells		(Markdown only)	(JS required)
Pagination	Manual Implementation	Built-in	Built-in
Sorting	Manual Implementation	Built-in	Built-in
Filtering	Manual Implementation	Built-in	Built-in
Column Resizing
Column Reordering
Fixed/Frozen Columns
Row Selection	Manual Implementation
Cell Editing	Manual Implementation
CSV Export	Manual Implementation
Excel Export	Manual Implementation		Enterprise Only
Row Grouping
Pivoting			Enterprise Only
Tree Data	Manual Implementation
Virtual Scrolling
Backend Pagination	Manual Implementation
Row Dragging
Column Spanning
Row Spanning
Setup Complexity	Simple	Moderate	Complex
Performance (Large Data)	Poor	Good	Good
Learning Curve	Minimal	Moderate	Steep

Legend: Supported out-of-the-box |  Not supported | Enterprise feature. ‘Manual Implementation’ means possible but requires custom development

6. Conclusion

We reviewed three ways to turn your CSV/Excel data into a table with Dash Python.

At the end, how to make your choice?

• Choose Bootstrap Table if you need a simple static display for small datasets (< 100 lines). It’s perfect for straightforward displays with minimal setup.
• Choose DataTable when you need built-in interactivity like sorting and filtering for medium-sized datasets. It’s also excellent for editable tables and offers a good balance of features without complexity.
• Choose AG Grid if you need to provide the best user experience on your data table, with Excel-like functionality and advanced styling. But it comes with the need of additional Javascript knowledge.

Opinion. I personally prefer to use Dash Bootstrap for static table displays. For more advanced interactive data display, I prefer AG Grid for its user experience, but achieving what I want to do is often complex.

Remember, you can always start with the simplest solution that meets your needs —many applications work perfectly fine with a basic Bootstrap table, and you can upgrade to more advanced components as your requirements grow.

I hope this article helped you to grasp the differences between the table providers!

Feel free to join the discussion or ask question on the associated topic here.

L’article How to create tables in plotly Dash (dbc.Table, DataTable, AG Grid comparison) est apparu en premier sur dash-resources.com.

The tutorial is in three parts:

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

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

Let’s go!

Introduction to Dash Mantine Components

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

Some key components we’ll use:

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

DMC uses several spacing and positioning attributes:

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

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

Step 1: Setting up the layout

1. Data structure

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

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

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

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

2. Creating reusable layout functions

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

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

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

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

    return content

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

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

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

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

3. Creating the tasks list and main container

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

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

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

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

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

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

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

    return content

4. Styling with CSS

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

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

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

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

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

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

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

This CSS does several things:

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

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

5. Running the app

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

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

# sample_list_data = ...

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

app = Dash(__name__)

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

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

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

See the full code on Github or open the app.

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

Step 2: Adding interactivity with callbacks

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

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

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

For example, compare these two approaches:

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

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

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

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

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

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

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

1. Adding unique identifiers

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

import uuid

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

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

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

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

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

    return content

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

2. Adding new tasks

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

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

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

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

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

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

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

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

3. Removing Tasks

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

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

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

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

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

    return current_tasks

Here’s how it works:

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

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

4. Run the app

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

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

# sample_list_data = ...

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

app = Dash(__name__)

# app.layout = ..

## Callbacks
# add_task()
# remove_task()

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

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

See the full code on Github or open the app.

You can also download the full project below:

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

Conclusion

Let’s recap what we covered in this article:

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

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

I hope you enjoyed this first part of the tutorial!

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

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

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

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

Let’s start!

A simple callback

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

The associated code is the following:

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

app = Dash(__name__)

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

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

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

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

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

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

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

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

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

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

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

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

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

Congratulations, you just learned the most essential feature of Dash

Multi input callback

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

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

Here’s how you can implement it:

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

app = Dash(__name__)

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

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

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

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

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

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

Multiple inputs and outputs callbacks

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

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

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

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

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

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

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

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

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

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

Multiple callbacks with the same inputs

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

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

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

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

# (... update counter)

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

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

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

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

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

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

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

Chained callbacks: callbacks triggering other callbacks

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

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

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

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

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

    return content, style

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

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

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

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

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

Here’s how we can implement it:

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

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

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

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

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

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

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

Using State instead of Input

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

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

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

Advantages and disadvantages of chaining callbacks

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

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

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

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

Other types of callbacks

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

Background Callbacks

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

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

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

Clientside Callbacks

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

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

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

Pattern-Matching Callbacks

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

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

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

Conclusion

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

To deepen your understanding of Dash callbacks, you can:

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

I hope you enjoyed this tutorial!

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

L’article Tutorial: Dash callbacks (schemas & examples) est apparu en premier sur dash-resources.com.

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

TL;DR. While Django is a perfect framework for traditional websites, Dash shines in creating interactive web applications easily. The choice depends on what you need to build and if you want 100% Python or not.

About Django

Django is a full-featured web framework that’s designed for building complex web applications. It excels at:

• Building traditional web applications with user authentication, database management, and admin interfaces
• Content management systems and e-commerce platforms
• RESTful API development
• Handling complex database operations with its powerful ORM
• Managing user sessions, forms, and security features

Example: Django is an excellent solution if you’re building an e-commerce website that needs user registration, product management, shopping carts, and payment processing.

It is also noteworthy that Django has a strong extension ecosystem and large community.

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
• Rapid prototyping of data visualization interfaces

Example : Dash is an excellent choice if you’re providing a web application with data visualization that requires a lot of interactivity, such as a monitoring & analysis platform.

Dash is a growing framework with a vibrant community. The recent framework updates tend to fill the gap for more classic website features (e.g. built-in URL routing was added in 2022).

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 Dash is better

The most distinctive built-in feature of Dash is its reactive callback system for building interactive data visualizations without JavaScript.

Here is a code example for Dash:

###### DASH EXAMPLE ######
from dash import Dash, dcc, html, Input, Output
import plotly.express as px

app = Dash(__name__)

app.layout = html.Div([
    dcc.Dropdown(
        id='category-dropdown',
        options=[{'label': x, 'value': x} for x in ['A', 'B', 'C']],
        value='A'
    ),
    dcc.Graph(id='interactive-graph')
])

@app.callback(
    Output('interactive-graph', 'figure'),
    Input('category-dropdown', 'value')
)
def update_graph(selected_category):
    # This automatically re-renders when dropdown changes
    df = get_data(selected_category)
    return px.scatter(df, x='x', y='y')

The code illustrates how straightforward it is. First we define the app layout containing a graph, then this graph is updated with a callback function (update_graph). That’s it!

It does not require any JavaScript code, everything is handled in Python.

To achieve the same in Django, we would need to build an API endpoint and use JavaScript to get the data, then plot the data. Let’s see the code:

###### DJANGO EXAMPLE ######
# urls.py
urlpatterns = [
    path('', views.dashboard, name='dashboard'),
    path('api/data/<str:category>', views.get_graph_data, name='get_graph_data'),
]

# views.py
def dashboard(request):
    return render(request, 'dashboard.html', {
        'categories': ['A', 'B', 'C']
    })

def get_graph_data(request, category):
    df = get_data(category)
    return JsonResponse({
        'x': df['x'].tolist(),
        'y': df['y'].tolist()
    })

# dashboard.html
{% block content %}
<select id="category-dropdown">
    {% for category in categories %}
        <option value="{{ category }}">{{ category }}</option>
    {% endfor %}
</select>
<div id="graph"></div>

<script>
// Need to write custom JavaScript for interactivity
document.getElementById('category-dropdown').addEventListener('change', function(e) {
    fetch(`/api/data/${e.target.value}`)
        .then(response => response.json())
        .then(data => {
            Plotly.newPlot('graph', [{
                x: data.x,
                y: data.y,
                type: 'scatter'
            }]);
        });
});
</script>
{% endblock %}

In Django, every interaction must be handcrafted (in vanilla JS or with a framework such as React or Angular). Dash provides it “out-of-the-box” and as well be paired with JavaScript or extended with React components if needed.

Where Django is better

Even if we can handle user login with Dash and flask-login, the out-of-the-box authentication is really basic. On the other hand, Django automatically handles CSRF protection, password hashing, and session security.

It also provides built-in protection against common vulnerabilities (XSS, CSRF, SQL injection) :

###### DJANGO EXAMPLE ######
# views.py
from django.contrib.auth.forms import UserCreationForm
from django.shortcuts import render, redirect

def register(request):
    if request.method == 'POST':
        form = UserCreationForm(request.POST)
        if form.is_valid():
            form.save()  # Handles password hashing, validation
            return redirect('login')
    return render(request, 'register.html', {'form': form})

# template
<form method="post">
    {% csrf_token %}  # CSRF protection automatic
    {{ form.as_p }}   # XSS protection automatic
    <button type="submit">Register</button>
</form>

With Dash, you need to implement these security features yourself (at the risk of not doing them correctly):

###### DASH EXAMPLE ######
from dash import Dash, html, dcc, Input, Output, State
from werkzeug.security import generate_password_hash
import secrets

app = Dash(__name__)
app.server.secret_key = secrets.token_hex(16)

app.layout = html.Div([
    # Must manually add CSRF token
    html.Div(id='csrf-token', style={'display': 'none'}, 
            children=secrets.token_hex(16)),
    dcc.Input(id='username', type='text'),
    dcc.Input(id='password', type='password'),
    html.Button('Register', id='register-button'),
])

@app.callback(
    Output('output', 'children'),
    Input('register-button', 'n_clicks'),
    State('username', 'value'),
    State('password', 'value'),
    State('csrf-token', 'children')
)
def register(n_clicks, username, password, csrf_token):
    if n_clicks:
        # Must manually implement:
        # - CSRF validation
        # - Input sanitization (XSS protection)
        # - Password validation
        hashed = generate_password_hash(password)
        # Manual database insertion with SQL injection protection

In that case, working with Django provides a safer and more stable base.

Dash plotly vs. Django: 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	Django	Dash	Notes
Admin Interface			Django’s auto-admin is unique
Database ORM		—	Django ORM vs SQLAlchemy/SQL
Authentication			Built-in vs Flask-Login
Template Engine			Django templates vs React
URL routing			Django routing is much more scalable
Internationalization (i18n)			Django has built-in i18n tools

Django shines in traditional web development with its comprehensive built-in features. The admin interface is particularly powerful, automatically generating a CRUD interface for your models. While Dash (through Flask) can achieve similar functionality, it requires additional setup and packages.

Data Visualization & Interactivity

Feature	Django	Dash	Notes
Interactive Graphs	—		Dash: deep Plotly integration
Real-time Updates	—		Dash: built-in reactivity
Callback System			Dash’s core feature
Component State	—		Dash: automatic state management

This is where Dash truly excels. Its reactive callback system allows you to build complex interactive visualizations without writing JavaScript. Components automatically update when their inputs change, making it easier and faster to build interactive web apps.

Development & Deployment

Django provides a more mature development environment with comprehensive testing tools and database migration systems. Dash, while having a smaller ecosystem, integrates seamlessly with data science tools like pandas and numpy.

Feature	Django	Dash	Notes
Testing Framework
Database Migrations			Django: built-in
Community			Django has larger ecosystem
Data Science Tools	—		Better integration with pandas/numpy

Both frameworks can be deployed similarly, but Django offers more out-of-the-box deployment options and production-ready features. That’s because Django benefits from a more mature ecosystem and developer community.

Conclusion

As you now understand, the difference between these two Python frameworks isn’t about their capability— they both provide the ability to develop any web application. It is more about how “built-in” certain features are.

At the end, the choice depends on 1) the type of website or web app you need to build and 2) your skill set:

• Choose Django if you need a stable framework to build a traditional website or if you have JavaScript knowledge to handle the interactivity.

• Choose Dash if you need to build an interactive web app that embeds some data visualization and/or if you only know Python.

I hope this article helped you better understand the differences between Django and Dash, just as it helped me!

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