DEV Community: India Owens

Action Buttons in Dataframes with Record-Level Routing in Shiny for Python

India Owens — Mon, 16 Mar 2026 01:35:45 +0000

Why this is more useful than a modal

This is Part 3 of the Shiny for Python: The Missing Manual series. Part 1 covered Quill.js rich text input, Part 2 covered multi-page routing with Starlette. This article builds directly on Part 2's routing setup — read that first if you haven't.

Adding action buttons to a dataframe is actually reasonably documented for Shiny — if you're using R. The Python documentation is sparse, and almost every tutorial I found stops at the same place: a button that triggers a modal dialog showing the record.

Modals are fine for simple use cases. But in a real internal tool, you often want something closer to how a normal web application behaves: a View button that opens a dedicated read-only page for the record, an Edit button that opens a form pre-populated with that record's data, and a Delete button that removes it in place. Each page lives at its own URL, the record ID is passed as a query parameter, and the server reads it to fetch the right data.

This article builds directly on the routing setup from Part 2. If you haven't read that, the short version is: we're using Starlette to mount multiple Shiny apps at different routes, all sharing a single server function. Here we're adding two new routes — /view_record and /edit_record — and wiring the dataframe buttons to navigate to them.

Two types of buttons, two different approaches

The three buttons we're building — View, Edit, Delete — fall into two distinct categories. Understanding the difference before you write any code will save you from a confusing debugging session.

Button	Type	How it works	Why
View	Link (`<a>` tag)	Navigates to `/view_record/?record_id=N` in a new tab	No action needed — just navigation with a param
Edit	Link (`<a>` tag)	Navigates to `/edit_record/?record_id=N` in a new tab	Same — destination page handles the logic
Delete	Button + JavaScript	JS calls `Shiny.setInputValue()`, Python reactive fires	Must trigger server-side logic in the current session

View and Edit are pure navigation — they don't need to talk to the Shiny server at all. Delete is different: it needs to actually execute something on the server, update the database, and refresh the table in the current page. That's why it uses the same JavaScript bridge pattern from Part 1.

Updated architecture

Starlette routes

main.py (Starlette)

├─ /submit ──────▶
submit.py

├─ /view ────────▶
view.py      
← buttons rendered here

├─ /view_record ─▶
view_record.py
?record_id=N

├─ /edit_record ─▶
edit_record.py
?record_id=N

└─ / ────────────▶
redirect → /submit

All pages import ▼

server.py (shared reactive logic + delete handler)

Reads/writes ▼

myshinyapp.db (SQLite)

Step 1: Add the two new page files

These are minimal — each one defines a navbar UI and imports the shared server. The actual content is rendered dynamically by the server function using the record ID from the URL.

view_record.py

view_record.py

from shiny import App, ui
from server import server_function

display_ui = ui.page_navbar(
    ui.nav_control(ui.a("← Back to Main", href="../submit")),
    ui.nav_panel(
        "Record View",
        ui.output_ui("view_record")
    )
)

app = App(display_ui, server_function)

edit_record.py

edit_record.py

from shiny import App, ui
from server import server_function

display_ui = ui.page_navbar(
    ui.nav_control(ui.a("← Back to Main", href="../submit")),
    ui.nav_panel(
        "Record Edit",
        ui.output_ui("edit_record")
    )
)

app = App(display_ui, server_function)

Step 2: Register the new routes in main.py

main.py — updated

from starlette.applications import Starlette
from starlette.routing import Mount, Route
from starlette.responses import RedirectResponse
from submit      import app as form_app
from view        import app as display_app
from view_record import app as view_record_app  # new
from edit_record import app as edit_record_app  # new

async def homepage_redirect(request):
    root_path = request.scope.get("root_path", "")
    return RedirectResponse(url=f"{root_path}/submit")

routes = [
    Mount("/submit",      app=form_app),
    Mount("/view",        app=display_app),
    Mount("/view_record", app=view_record_app),  # new
    Mount("/edit_record", app=edit_record_app),  # new
    Route("/",            endpoint=homepage_redirect),
]

app = Starlette(routes=routes)

Step 3: Render the action buttons in the dataframe

The buttons are injected into the dataframe as raw HTML using ui.HTML() applied row-by-row with df.apply(). Each row gets three buttons: View and Edit as anchor tags with the record ID baked into the URL, and Delete as a button that fires a JavaScript callback.

💡 Where this lives The action_buttons() helper and the JavaScript file both live in server.py and js/buttons.js respectively. The helper is called every time the table is (re)rendered — including after a delete.

server.py — action_buttons helper

server.py (excerpt)

from urllib.parse import parse_qs
from shiny.ui import icon_svg  # Bootstrap icons built into Shiny

def action_buttons(df):
    """Inject View / Edit / Delete buttons into each row of the dataframe."""
    df['action'] = df.apply(
        lambda row: ui.HTML(
            f"""
            <div class="btn-group" role="group">
              <!-- View: anchor tag, opens record detail in new tab -->
              <a class="btn btn-sm btn-outline-secondary"
                 href="/view_record/?record_id={row['id']}"
                 target="_blank"
                 title="View">
                {icon_svg("eye")}
              </a>
              <!-- Edit: anchor tag, opens edit form in new tab -->
              <a class="btn btn-sm btn-outline-secondary"
                 href="/edit_record/?record_id={row['id']}"
                 target="_blank"
                 title="Edit">
                {icon_svg("pencil")}
              </a>
              <!-- Delete: button + JS callback, acts in current session -->
              <button class="btn btn-sm btn-outline-danger"
                      id="delete_{row['id']}"
                      title="Delete"
                      type="button"
                      onclick="get_delete_id(this.id)">
                {icon_svg("trash")}
              </button>
            </div>
            """
        ),
        axis=1
    )
    return df

Step 4: The JavaScript delete bridge

The Delete button can't use an anchor tag because it needs to trigger server-side logic — not navigate. The pattern is the same as the Quill bridge in Part 1: JavaScript captures the click, reads the button's ID to extract the record ID, and pushes it into Shiny's reactive graph via setInputValue().

js/buttons.js

js/buttons.js

function get_delete_id(clicked_id) {
    // clicked_id looks like "delete_5"
    // We push the whole string and parse it on the Python side
    console.log("Delete clicked:", clicked_id);
    Shiny.setInputValue('current_delete_id', clicked_id, { priority: 'event' });
}

⚠️ Don't forget to include the JS file Add ui.include_js(Path(__file__).parent / "js" / "buttons.js") to the ui.page_navbar() call in view.py — the page that renders the table. Without it, clicking Delete silently does nothing.

⚠️ render.data_frame not render.table render.table strips custom HTML from cell content — your ui.HTML() buttons will silently disappear with no error. Use render.data_frame and ui.output_data_frame() instead, which preserves the button markup.

server.py — data_table render function

server.py (excerpt)

# IMPORTANT: @render.data_frame not @render.table
    # render.table strips custom HTML — your buttons will silently disappear
    @render.data_frame
    @reactive.event(input.refresh, ignore_none=False)
    def data_table():
        with sqlite3.connect(DB_NAME) as conn:
            df = pd.read_sql_query(
                "SELECT * FROM name ORDER BY id DESC", conn
            )
        return action_buttons(df)

Step 5: The delete handler in server.py

When JavaScript fires setInputValue('current_delete_id', ...), Shiny's reactive system picks it up and the handler below runs. It parses the record ID out of the button ID string, deletes the row, and re-renders the table with fresh data.

server.py — delete handler

server.py (excerpt)

@reactive.effect
@reactive.event(input.current_delete_id)
async def delete_record():
    button_id_str = input.current_delete_id()

    try:
        # "delete_5" → split on "_" → take index 1 → cast to int
        record_id = int(button_id_str.split("_")[1])

        with sqlite3.connect(DB_NAME) as conn:
            conn.execute("DELETE FROM name WHERE id = ?", (record_id,))
            ui.notification_show(f"Record {record_id} deleted.", type="warning")

            # Re-fetch and re-render the table with buttons injected
            df = pd.read_sql_query(
                "SELECT * FROM name ORDER BY id DESC", conn
            )
            await data_tables.update_data(action_buttons(df))

    except Exception as e:
        ui.notification_show(f"Delete failed: {e}", type="error")

Step 6: Reading the record ID from the URL

When a user clicks View or Edit, the browser navigates to a new tab at /view_record/?record_id=5. The server function on that page needs to extract the ID from the URL query string and use it to fetch the right record. Shiny exposes this through session.clientdata.url_search().

Because multiple render functions on the page may need this ID, we store it in a reactive.value that gets set once on page load and read wherever it's needed.

server.py — extracting the URL param

server.py (excerpt)

from urllib.parse import parse_qs

# Reactive value to hold the record ID — set once, read anywhere
id = reactive.value("")

@reactive.effect
def initialize_from_query_params():
    # url_search() returns the raw query string, e.g. "?record_id=5"
    url_query = session.clientdata.url_search()
    params = parse_qs(url_query.lstrip("?"))

    if "record_id" in params:
        id.set(params["record_id"][0])

✅ Why reactive.value and not a local variable reactive.value integrates with Shiny's reactive graph — any render function that calls id.get() will automatically re-run if the value changes. A plain Python variable won't trigger re-renders.

Step 7: The view and edit render functions

Both functions follow the same pattern: get the ID, query the database with a parameterized query (never string interpolation — SQL injection is a real risk even in internal tools), handle the empty case gracefully, then return Shiny UI elements.

server.py — view_record render function

server.py (excerpt)

@render.ui
def view_record():
    record_id = id.get()

    if not record_id:
        return ui.p("No record selected.")

    with sqlite3.connect(DB_NAME) as conn:
        record = pd.read_sql_query(
            "SELECT * FROM name WHERE id = ?",
            conn,
            params=(record_id,)
        )

    if record.empty:
        return ui.p(f"Record {record_id} not found.")

    return ui.div(
        ui.h2(f"Record {record_id}"),
        ui.p(ui.strong("First Name: "), record.at[0, 'first_name']),
        ui.p(ui.strong("Last Name: "),  record.at[0, 'last_name']),
    )

server.py — edit_record render function + update handler

server.py (excerpt)

@render.ui
def edit_record():
    record_id = id.get()

    if not record_id:
        return ui.p("No record selected.")

    with sqlite3.connect(DB_NAME) as conn:
        record = pd.read_sql_query(
            "SELECT * FROM name WHERE id = ?",
            conn,
            params=(record_id,)
        )

    if record.empty:
        return ui.p(f"Record {record_id} not found.")

    return ui.div(
        ui.TagList(
            ui.h2(f"Edit Record {record_id}"),
            ui.input_text("first_name", "First Name", value=record.at[0, 'first_name']),
            ui.input_text("last_name",  "Last Name",  value=record.at[0, 'last_name']),
            ui.input_action_button("submit_update", "Save Changes", class_="btn-primary"),
            ui.output_text("status"),
        )
    )

@reactive.effect
@reactive.event(input.submit_update)
def submit_update():
    try:
        with sqlite3.connect(DB_NAME) as conn:
            conn.execute(
                "UPDATE name SET first_name = ?, last_name = ? WHERE id = ?",
                (input.first_name(), input.last_name(), id.get())
            )
            conn.commit()
    except Exception as e:
        ui.notification_show(f"Update failed: {e}", type="error")

@render.text
def status():
    if input.submit_update() > 0:
        return f"Record {id.get()} updated successfully."
    return ""

Gotchas worth knowing

Use render.data_frame, not render.table. This is the most common gotcha with this pattern. render.table strips custom HTML from cell content — the ui.HTML() buttons you inject via action_buttons() will silently disappear and you'll have no idea why. render.data_frame preserves the button markup. Use ui.output_data_frame() in your UI to match.
Always use parameterized queries. Never use f-strings to interpolate record IDs directly into SQL. WHERE id = ? with params=(record_id,) is the correct pattern — even for internal tools.
The shared server means input IDs must be unique across pages. If view.py and edit_record.py both have an input named first_name, they won't conflict because each page is its own Shiny session — but be aware that the server function handles inputs from all pages, so naming collisions in your render logic can cause subtle bugs.
View and Edit open in a new tab (target="_blank"). This is intentional — the user stays on the table page and reviews or edits records in separate tabs. Remove target="_blank" if you want in-place navigation instead.
The delete handler re-injects buttons after every delete. Always pass the dataframe through action_buttons() before calling data_table.update_data(). If you forget, the refreshed table will render without buttons.
id.get() returns an empty string on pages where no record ID is in the URL. The if not record_id guard at the top of each render function handles this gracefully — without it, the SQL query will run with an empty string and return confusing results.

What you now have

A fully functional multi-page CRUD interface in Shiny for Python: a table with per-row View, Edit, and Delete buttons, dedicated pages for record detail and editing, URL-parameter-driven data loading, and in-place deletes that refresh the table without a page reload. This is the pattern most internal data tools actually need, and it's almost entirely undocumented for the Python version of Shiny.

That wraps up the Shiny for Python: The Missing Manual series. Part 1 covered extending Shiny with Quill.js, Part 2 covered multi-page routing with Starlette, and this article tied them together into a full CRUD interface. The complete working code for all three parts is available on GitHub.

References

Adding Action Buttons in Rows of DT Data Table in R Shiny — That Data Though (R — the foundational tutorial that inspired this approach)
Shiny for Python — session.ClientData API Reference — Posit (used for url_search())

Multi-Page Routing in Shiny for Python with Starlette

India Owens — Mon, 16 Mar 2026 01:31:42 +0000

The problem with existing routing examples

This is Part 2 of the Shiny for Python: The Missing Manual series. Part 1 covered extending Shiny with Quill.js for rich text input. This article stands alone, but if you're building a full internal tool, reading them in order will give you the complete picture.

Search for Shiny for Python routing and you'll find the same pattern repeated: one Shiny app mounted at one route, one static HTML page at another. It demonstrates the concept, but it doesn't solve the real problem.

In a production internal tool, you typically want something that behaves like a normal website — multiple pages, clean URLs, consistent navigation, and critically, shared server state across all of them. Maybe page one is a data entry form and page two is a live view of the database. The navigation bar links them, but they're running the same reactive logic underneath.

That's what this article covers. We'll build a two-page application: a form that writes names to a SQLite database, and a table view that reads from it. Both pages share a single server function, and Starlette handles the routing that ties them together.

Architecture overview

Before the code, here's how the pieces fit together:

Request from browser

Starlette (main.py)

─ /submit ──▶

submit.py (form UI)

Starlette (main.py)

─ /view ────▶

view.py (table UI)

Both import ▼

server.py (shared reactive logic)

Reads/writes ▼

myshinyapp.db (SQLite)

The key architectural decision is the shared server. Both Shiny apps import the same server_function from server.py. In a simple demo this doesn't matter much, but in a real application where pages share global state, utility functions, database connections, or config — this structure pays off immediately. It also keeps the codebase clean as the app grows.

💡 Two patterns, pick one You can also use Starlette to mount completely separate Shiny apps under different routes without sharing a server — useful if the pages are truly independent. This article shows the shared-server pattern because it's the more production-relevant one and the less documented one.

File structure

project layout

your_app/
├── main.py        # Starlette app — the entry point for uvicorn
├── server.py      # Shared Shiny server function
├── submit.py      # Form page UI + App object
├── view.py        # Table view page UI + App object
└── myshinyapp.db  # SQLite database (created on first run)

Step 1: The shared server

Start here because everything else depends on it. The server function handles all reactivity for both pages — form submission, database writes, and table rendering. Separating it into its own file isn't just organizational preference: it's what makes sharing it between two App objects possible.

server.py

server.py

import sqlite3
import pandas as pd
from shiny import render, reactive

DB_NAME = "myshinyapp.db"

# Initialize the database table if it doesn't exist yet
def init_db():
    with sqlite3.connect(DB_NAME) as conn:
        conn.execute(
            """CREATE TABLE IF NOT EXISTS name (
                id INTEGER PRIMARY KEY AUTOINCREMENT,
                first_name TEXT NOT NULL,
                last_name  TEXT NOT NULL
            )"""
        )

init_db()

def server_function(input, output, session):

    @render.table
    @reactive.event(input.refresh, ignore_none=False)
    def data_table():
        # ignore_none=False means the table loads on page open
        # without the user having to click Refresh first
        with sqlite3.connect(DB_NAME) as conn:
            return pd.read_sql_query(
                "SELECT * FROM name ORDER BY id DESC", conn
            )

    @render.text
    @reactive.event(input.submit)
    def status():
        first_name = input.first_name()
        last_name  = input.last_name()
        if first_name and last_name:
            with sqlite3.connect(DB_NAME) as conn:
                conn.execute(
                    "INSERT INTO name (first_name, last_name) VALUES (?, ?)",
                    (first_name, last_name)
                )
            return f"Saved: {first_name} {last_name}"
        return "Please enter both first and last name."

✅ Note on ignore_none=False Setting ignore_none=False on the refresh handler means the table renders immediately when the page loads — the user doesn't have to click Refresh to see data. Remove it if you want explicit user-triggered loads only.

Step 2: The page UIs

Each page is its own Python file with its own UI definition and its own App object — but both import the same server function. The navigation links use relative paths (../submit, ../view) which Starlette resolves correctly once the routes are mounted.

submit.py — the data entry form

submit.py

from shiny import App, ui
from server import server_function

form_ui = ui.page_navbar(
    ui.nav_panel(
        "Data Entry Form",
        ui.card(
            ui.input_text("first_name", "First Name"),
            ui.input_text("last_name",  "Last Name"),
            ui.input_action_button("submit", "Submit", class_="btn-primary"),
            ui.output_text("status"),
        )
    ),
    # Nav link to the other page — relative path resolved by Starlette
    ui.nav_control(ui.a("Database Viewer", href="../view")),
)

app = App(form_ui, server_function)

view.py — the database table

view.py

from shiny import App, ui
from server import server_function

display_ui = ui.page_navbar(
    ui.nav_control(ui.a("Data Entry Form", href="../submit")),
    ui.nav_panel(
        "Database Viewer",
        ui.input_action_button("refresh", "Refresh Table"),
        ui.hr(),
        ui.output_table("data_table"),
    )
)

app = App(display_ui, server_function)

Step 3: Starlette ties it all together

This is the file Uvicorn runs. Starlette mounts each Shiny App object at its respective route, and a root redirect handler means users who navigate to / land on the form automatically rather than hitting a 404.

⚠️ Don't skip the root redirect Without it, users have to manually navigate to yourapp.com/submit. That's fine in development but breaks the experience in production. The redirect adds three lines and costs nothing.

main.py — the Starlette entry point

main.py

from starlette.applications import Starlette
from starlette.routing import Mount, Route
from starlette.responses import RedirectResponse
from submit import app as form_app
from view import app as display_app

async def homepage_redirect(request):
    # Preserve the root_path so this works behind a reverse proxy
    root_path = request.scope.get("root_path", "")
    return RedirectResponse(url=f"{root_path}/submit")

routes = [
    Mount("/submit", app=form_app),
    Mount("/view",   app=display_app),
    Route("/",       endpoint=homepage_redirect),
]

# This is what uvicorn targets — not the individual Shiny apps
app = Starlette(routes=routes)

Running the app

Because Starlette is the outer application, you run main.py via Uvicorn — not the individual Shiny files directly:

terminal

# Install dependencies if you haven't already
pip install shiny starlette uvicorn pandas

# Run the app
uvicorn main:app --reload

# App is now available at:
#   http://localhost:8000/         → redirects to /submit
#   http://localhost:8000/submit   → data entry form
#   http://localhost:8000/view     → database table

Gotchas worth knowing before you hit them

The shared server doesn't mean shared reactive state between pages. Each page gets its own Shiny session when a user visits it. Shared server means shared code — database connections, utility functions, constants — not a live reactive context that persists across page navigations.
Navigation links use relative paths. ../submit and ../view are resolved by Starlette relative to the mounted route. If you change your mount paths in main.py, update the href values in your UI files to match.
Run via main.py, not the individual Shiny files. Running shiny run submit.py directly will work in isolation but won't give you routing. Uvicorn on main.py is the correct entry point for the full application.
The root_path in the redirect matters behind a proxy. If you're deploying behind Nginx or a similar reverse proxy that strips a path prefix, request.scope.get('root_path', '') ensures the redirect still lands correctly. Don't hardcode the base URL.

💡 When to use this pattern vs. separate apps Use the shared server pattern when your pages need common utility functions, share global config, or access the same database connection pool. Use fully separate Shiny apps mounted under different routes when the pages are genuinely independent and you want clean isolation — for example, separate tools for separate teams under one domain.

What this unlocks

With Starlette routing in place, Shiny for Python can behave like a real multi-page web application — clean URLs, shared logic, and a consistent navigation experience. The pattern scales cleanly: adding a third page means creating a new UI file, importing the server, and adding one more Mount in main.py.

The full working code for both versions is available on GitHub. The next part of this series covers adding interactive buttons directly inside a dataframe — and using routing and URL parameters to navigate to an individual record's detail page, building on the multi-page pattern we set up here.

References

Shiny for Python — Official Routing Documentation — Posit
Shiny for Python Routing — Appsilon
Shiny Router: A Simple Routing Package for Shiny — Appsilon (R only — no Python package yet, but useful for understanding the pattern)

Adding Rich Text to Shiny for Python with Quill.js

India Owens — Mon, 16 Mar 2026 01:30:26 +0000

If you've been building internal data tools with Shiny for Python and hit the wall where your users need to format text — bold, italics, headings, the works — you've probably noticed there's no native rich text component. There's a good reason for that: Shiny is designed for lightweight, reactive data applications, not document editors.

But production doesn't care about design philosophy. I ran into this exact situation building an internal specification management tool: the application had to support rich text because the analysts using it needed formatted notes alongside their data inputs. Shiny was the right framework for everything else, so I needed a way to extend it rather than abandon it.

The solution is Quill.js — an API-driven rich text editor that plays nicely with Shiny's JavaScript extension model. This article walks through exactly how to wire them together, including the production-grade version with a task button that handles async database submissions.

⚠️ Before you reach for this Only do this if you genuinely need rich text. Shiny doesn't support it natively for a reason — the added complexity is real. If plain text works for your use case, use ui.input_text_area() and move on.

Setup and prerequisites

One important decision before you start: use Shiny Core, not Shiny Express. I initially built this in Express and ran into deployment issues when the app was hosted on a Shiny Server I didn't control. Core is more explicit and more predictable across environments. If you're unsure which to use, the official comparison is worth reading — but for anything heading to production, Core is the safer choice.

You'll need two files:

app.py — your Shiny application
js/app.js — the JavaScript bridge between Quill and Shiny

No pip installs needed. Quill loads from a CDN directly in your app's <head>.

How the communication works

Before the code, it's worth understanding why the integration is structured the way it is. Shiny's reactive system only knows about inputs it defines — and Quill's editor lives entirely outside that system. To bridge them, we use Shiny's custom message API:

When the user clicks Submit, Python sends a custom message to JavaScript via session.send_custom_message()
JavaScript receives it, reads the Quill editor content, and pushes it back to Python using Shiny.setInputValue()
Python's reactive system picks it up as a regular input and handles it from there

💡 Key detail When you have multiple Quill editors, the last setInputValue() call should use {priority: 'event'}. This forces Shiny to treat it as a new event even if the value hasn't changed, ensuring your reactive handler always fires. Trigger your reactive on this last input.

Part 1: Basic implementation with an action button

Step 1 — app.py

app.py

from shiny import App, reactive, render, ui
from pathlib import Path

js_file = Path(__file__).parent / "js" / "app.js"

app_ui = ui.page_fluid(
    ui.tags.head(
        # Load Quill stylesheet from CDN
        ui.tags.link(
            rel="stylesheet",
            href="https://cdn.jsdelivr.net/npm/[email protected]/dist/quill.snow.css"
        ),
        # Load Quill library from CDN
        ui.tags.script(
            src="https://cdn.jsdelivr.net/npm/[email protected]/dist/quill.js"
        ),
    ),
    ui.include_js(js_file),
    ui.card(
        ui.card_header("Quill Input Demo"),
        ui.input_text(
            id="shiny_input_text",
            label="Standard Shiny Text Input",
        ),
        # Option A: initialize Quill on an HTML element
        ui.HTML('<div id="quill-text-box-using-HTML"></div>'),
        # Option B: initialize Quill on a div tag
        ui.tags.div(id="quill-text-box-using-div"),
        ui.output_ui("handle_rich_text"),
        ui.input_action_button("submit", "Submit"),
    )
)

def server(input, output, session):

    @reactive.effect
    @reactive.event(input.submit)
    async def handle_submit():
        # Signal JavaScript to read and return Quill content
        await session.send_custom_message(
            "get_quill_content", {"message": "get_quill_content"}
        )

    @render.ui
    @reactive.event(input.div_editor_raw_rich)  # trigger on the LAST input set
    def handle_rich_text():
        return ui.TagList(
            ui.tags.p("Standard text input:"),
            ui.tags.p(input.shiny_input_text()),
            ui.tags.p("Quill plain text:"),
            ui.tags.p(input.html_editor_plain_text()),
            ui.tags.p("Quill raw HTML:"),
            ui.tags.p(input.div_editor_raw_rich()),
        )

app = App(app_ui, server)

Step 2 — js/app.js

js/app.js

$(document).on('shiny:connected', function(event) {

    // Initialize both Quill editors once Shiny is ready
    var html_editor = new Quill('#quill-text-box-using-HTML', {
        theme: 'snow',
        bounds: '#quill-text-box-using-HTML'
    });

    var div_editor = new Quill('#quill-text-box-using-div', {
        theme: 'snow',
        bounds: '#quill-text-box-using-div'
    });

    // Listen for Python's signal to read editor content
    Shiny.addCustomMessageHandler('get_quill_content', function(message) {

        var html_editor_plain_text = html_editor.getText();
        var div_editor_raw_rich = div_editor.root.innerHTML;

        // Set the plain text value first
        Shiny.setInputValue('html_editor_plain_text', html_editor_plain_text);

        // Set the rich HTML value LAST, with priority: 'event'
        // This ensures Shiny fires the reactive even if content hasn't changed
        Shiny.setInputValue('div_editor_raw_rich', div_editor_raw_rich, {
            priority: 'event'
        });
    });
});

Part 2: Production version with a task button

The action button version works for simple demos. But in a real application where submitting the form triggers database writes or API calls, you need the UI to reflect that the app is busy. That's where input_task_button comes in — it has built-in busy and ready states. The catch is that async tasks change how you structure the Quill handoff.

The key addition is @reactive.extended_task, which lets the Quill message round-trip complete asynchronously before the rest of your submit logic runs. Without it, your reactive handler fires before JavaScript has had a chance to push the Quill content back to Python.

app.py — production version

from shiny import App, reactive, render, ui
from pathlib import Path

js_file = Path(__file__).parent / "js" / "app.js"

app_ui = ui.page_fluid(
    ui.tags.head(
        ui.tags.link(
            rel="stylesheet",
            href="https://cdn.jsdelivr.net/npm/[email protected]/dist/quill.snow.css"
        ),
        ui.tags.script(
            src="https://cdn.jsdelivr.net/npm/[email protected]/dist/quill.js"
        ),
    ),
    ui.include_js(js_file),
    ui.card(
        ui.card_header("Quill Input Demo"),
        ui.input_text(id="shiny_input_text", label="Standard Text Input"),
        ui.HTML('<div id="quill-text-box-using-HTML"></div>'),
        ui.tags.div(id="quill-text-box-using-div"),
        # auto_reset=False keeps the button in "busy" state
        # until we explicitly reset it after the async work completes
        ui.input_task_button("submit", "Submit", auto_reset=False),
    )
)

def server(input, output, session):

    @reactive.extended_task
    async def get_rich_text():
        # Signal JS to read Quill and push values back to Python
        await session.send_custom_message(
            "get_quill_content", {"message": "get_quill_content"}
        )

    @reactive.effect
    @reactive.event(input.submit)
    def handle_submit():
        # Put the button into busy state immediately on click
        ui.update_task_button("submit", state="busy")
        # Kick off the async Quill read
        get_rich_text()

    @reactive.effect
    @reactive.event(input.div_editor_raw_rich)  # fires after JS sets the last value
    def handle_rich_text():
        # At this point all Quill values are available in input.*
        # Do your database write or API call here

        # Reset button to ready state when work is complete
        ui.update_task_button("submit", state="ready")

app = App(app_ui, server)

✅ Why extended_task matters here @reactive.extended_task allows the async message round-trip (Python → JS → Python) to complete without blocking Shiny's reactive graph. Without it, handle_rich_text could fire before JavaScript has pushed the Quill content back, and you'd get empty or stale values.

Gotchas I hit in production

A few things that will cost you time if you don't know them going in:

Shiny Express broke on my server. I started with Express, hit deployment issues on a Shiny Server I didn't control, and switched to Core. If you're self-hosting or deploying to a managed server, Core is safer.
Order of setInputValue calls matters. Always set your "trigger" input — the one your reactive listens to — last, and always with {priority: 'event'}. If you set it first, Shiny might not register the earlier values in time.
Don't initialize Quill before shiny:connected. If Quill initializes before Shiny's session is ready, the custom message handler won't exist yet and the bridge silently breaks.
Quill returns HTML, not plain text. div_editor.root.innerHTML gives you raw HTML with tags. If you're storing to a database, decide upfront whether you want the HTML or the plain text (editor.getText()), and sanitize accordingly before writing.

When to use this — and when not to

This pattern works well for internal tools where you control the environment and your users need formatted input alongside data. It's less appropriate if Shiny isn't already your framework of choice, or if rich text is the primary feature rather than a supporting one — in that case, a dedicated web framework will serve you better.

The full working code for both versions is available on GitHub. The next part of this series covers multi-page routing in Shiny for Python with Starlette — building the foundation that lets the form we built here live alongside a database view page under a single application and URL structure.

References

Quill.js Quickstart — Quill
Shiny Express vs Core — Posit