shinyreact

Building Custom Shiny UI with React

Barret Schloerke

posit / Shiny Team

@schloerke

Old Faithful

Today I want to talk about using React.js within your Shiny applications. But before I do that, I want to talk about my favorite Shiny application. Everyone remembers their first… app, and mine was Old Faithful.

I have been building Shiny apps since 2016 and been on the Shiny Team since 2018. The Old Faithful app is the kind of app that made me love Shiny: one input, one plot, a complete interactive application in just a few lines of R.

And this app is still Old Faithful in another sense: dependable, familiar, and exactly the UI we have all seen before.

Old Faithful

#| '!! shinylive warning !!': |
#|   shinylive does not work in self-contained HTML documents.
#|   Please set `embed-resources: false` in your metadata.
#| standalone: true
#| components: [viewer]
#| viewerHeight: 1080
library(shiny)
library(bslib)

ui <- page_sidebar(
  # Sized for a projector, not a laptop: this runs at 1:1 with the 1920x1080
  # canvas, same as the other two demos' `html { font-size: 26px }`.
  theme = bs_theme(font_scale = 1.6),
  # ionRangeSlider's parts are fixed px whatever the font size is: 11px bubble,
  # 10px min/max, 9px grid, a 3px bar and a 19px handle. Scaling the whole
  # widget with a transform fixes the size but shrinks the track to match, so
  # the parts are resized instead - each `top` re-centred on the same 40px axis.
  # `.irs-bar` needs `!important`: bslib's own rule lands after this style tag.
  tags$style(HTML("
    .irs--shiny { height: 80px; }
    .irs--shiny .irs-line { height: 8px; top: 36px; border-radius: 4px; }
    .irs--shiny .irs-bar { height: 8px !important; top: 36px !important; }
    .irs--shiny .irs-handle { width: 32px; height: 32px; top: 24px; }
    .irs--shiny .irs-single { font-size: 20px; top: 0; padding: 2px 10px; }
    .irs--shiny .irs-min, .irs--shiny .irs-max { font-size: 18px; top: 0; padding: 2px 8px; }
    .irs--shiny .irs-grid { top: 52px; height: 24px; }
    .irs--shiny .irs-grid-text { font-size: 16px; top: 12px; }
  ")),
  # shinylive runs this app in an iframe, so reveal never sees these keys. Hand
  # them back via reveal's postMessage API: triggerKey runs whatever reveal has
  # bound to the code. PageUp/PageDown is what most presenter remotes send and
  # no widget wants them, so they always go to the deck; a focused slider owns
  # the arrows and space, or advancing the deck would also drag the control.
  # Identical in all three demos (apps/0{1,2}-*/www/index.html) - change one,
  # change all three.
  tags$script(HTML('
    const deckKeys = { PageUp: 33, PageDown: 34 };
    const sharedKeys = { ArrowLeft: 37, ArrowUp: 38, ArrowRight: 39, ArrowDown: 40, " ": 32, Escape: 27 };
    addEventListener("keydown", (e) => {
      const widget = e.target instanceof Element &&
        e.target.closest("input, select, textarea, button, [contenteditable]");
      const keyCode = deckKeys[e.key] || (widget ? 0 : sharedKeys[e.key]);
      if (keyCode && parent !== window) {
        parent.postMessage(JSON.stringify({ method: "triggerKey", args: [keyCode] }), "*");
      }
    });
  ')),
  title = "Hello Shiny!",
  sidebar = sidebar(
    width = 420,
    sliderInput(
      inputId = "bin_count",
      label = "Number of bins:",
      min = 1,
      max = 50,
      value = 30
    )
  ),

  plotOutput(outputId = "distPlot")
)

server <- function(input, output) {
  # The plot's text is in device pixels, so `font_scale` does not reach it;
  # `res` is the lever for the chart, as the svg's width is for the React one.
  output$distPlot <- renderPlot({
    x <- faithful$waiting
    breaks <- seq(min(x), max(x), length.out = input$bin_count + 1)

    hist(
      x,
      breaks = breaks,
      col = "#75AADB",
      border = "white",
      xlab = "Waiting time to next eruption (in mins)",
      main = "Histogram of waiting times"
    )
  }, res = 130)
}

shinyApp(ui = ui, server = server)

Let’s dig into the code.

Ownership

• R owns both the UI definition and the reactive computation.

UI

ui <- bslib::page_sidebar(
  sidebar = bslib::sidebar(
    sliderInput(
      "bin_count",
      label = "Number of bins:",
      min = 1, max = 50,
      value = 30
    )
  ),
  plotOutput("distPlot")
)

Server

server <- function(input, output) {
  output$distPlot <- renderPlot({
    x <- faithful$waiting
    n <- input$bin_count
    breaks <- seq(min(x), max(x),
                  length.out = n + 1)
    hist(x, breaks = breaks)
  })
}

The R UI is wonderful… until it isn’t

• For an app like this, bslib gets you from nothing to something to be proud of

Custom UI… within a string

• How many of you have written JavaScript or CSS within a string?

app.R

ui <- bslib::page_sidebar(
  tags$head(tags$style(HTML("
    .stat-card { display: grid; gap: .5rem; cursor: pointer; }
  "))),
  tags$script(HTML("
    $(document).on('click', '.stat-card', function() {
      Shiny.setInputValue('card_clicked', this.dataset.id);
    });
  ")),
  uiOutput("cards")
)

Ask it. Wait for the hands. Then thin them out, one question at a time — each one should drop some hands and leave the rest more committed:

• “Keep them up if that string was more than ten lines.” (most stay up)
• “Keep them up if it was more than a hundred.” (fewer — and those are the people this talk is for)
• “Keep them up if you wrote it without one squiggly underline telling you you’d made a typo.” (they all stay up; nothing in R was ever going to underline it)
• (hands down) “And how many of you have thought about just using a real JavaScript framework instead?” (hands again — this is the turn; the room has already had the idea, and the rest of the talk is permission to act on it)

bslib got us from nothing to something to be proud of. Then a request comes in — a distinctive interface, richer interaction, a component from a modern design system — and there is no bslib function for it. So you reach for this.

And look at what the slide is showing you. All of that is one colour, because to R it is one thing: text.

• Your editor thinks this is a string.
• Your linter thinks this is a string.
• Your formatter, your tests, your diff — all of them think this is a string.

It’s a program.

So: you are already writing JavaScript. You are just writing it in the one place where nothing can help you. Hold onto that — we come back to it.

I do not want to replace Shiny. The reactive data model is your domain expertise. Keep Shiny for reactive computation, and use a modern UI ecosystem — React.js — for the interface. React is not adding JavaScript to your app; it is taking the JavaScript you already wrote out of the string.

React

React.dev

• The library for web and native user interfaces

• “…build user interfaces out of individual pieces called components”

React calls itself “the library for web and native user interfaces”, and you build those interfaces out of individual pieces called components.

Components

• A component is a function that returns HTML-like markup.

Stat.tsx

function Stat({ label, value }) {
  const name = label.toUpperCase();
  return (
    <div className="stat">
      <span className="stat-label">{name}</span>
      <span className="stat-value">{value}</span>
    </div>
  );
}
<Stat label="Eruptions" value={272} />
<Stat label="Bins" value={30} />

Rendered

ERUPTIONS 272

BINS 30

A component is a function that returns HTML-like markup. Define Stat once, and you use it as <Stat> — twice here, and it draws twice. That is the whole idea: you name a piece of UI, and then you reuse it.

Components draw data’s state

waiting = [79, 54, 74, 62, …]bin_count = 12 → bins = [13, 19, 31, 20, …] →

waiting = [79, 54, 74, 62, …]bin_count = 30 → bins = [1, 8, 7, 10, …] →

React is REALLY good at just taking JSON and mapping data to UI.

You describe what the UI looks like for a given state — and don’t worry about managing the transitions from one data state to another!

Old Faithful is the whole idea in one picture: the same 272 waiting times go in, bin_count reduces them to a bins array, and that array is the chart. The only thing that changed between these two is the number. Nobody added, removed, or resized a bar.

Old Faithful

Same app, no Shiny at all — this is 100% React, and the data is baked into the page.

Drag the slider. Every bar moves. I did not write a single line that adds, removes, or resizes a bar.

Old Faithful

app.tsx

function App() {
  const [binCount, setBinCount] = useState(30);
  const bins = useMemo(
    () => bin_data(waiting, binCount),
    [binCount]
  );

  return (
    <main className="layout">
      <label htmlFor="bin_count">Number of bins:</label>
      <input id="bin_count" type="range" value={binCount}
             onChange={(e) => setBinCount(Number(e.target.value))} />
      <Histogram bins={bins} />
    </main>
  );
}

bin_count is the only state in the app. bins is derived from it — React recomputes it when, and only when, bin_count changes.

Then the whole UI is described once, for whatever bin_count happens to be. New state, new description, and React works out the difference.

Hold on to those two lines. In a few minutes the only thing that changes is where they get their values from.

Why React?

• Massive adoption in the JS community
  • GitHub:
  • react alone pulled 170M downloads last week
    • Shiny has 50M downloads in 14 years!
• Proven component libraries, design systems, charts, tables, maps

A MASSIVE ecosystem of proven components, ready for production environments. It dwarfs what R and Python readily have available.

Thirty million repositories on GitHub depend on React.

And react alone pulled 170 million downloads last week — more than three times Shiny’s entire 14-year total on CRAN, which is about 50 million.

Show off existing libraries.

Why Shiny + React?

+

• 🚫 Hand-rolled HTML and JavaScript in Shiny
• 🧰 Use the proper tool for the job
• 🤖 AI excels at building well-known frameworks

Those hands you put up earlier — that is this first bullet. It works, right up until the app gets big, and then you are the framework.

I’m happy to do car maintenance with a multitool. But using the proper tool for the job saves time, effort, and the skin on your knuckles. React is that tool: it is what the rest of the world reaches for when a UI outgrows being hand-assembled.

And it is the tool your assistant already knows. An LLM has seen millions of React components and approximately none of your bespoke tags$div() scaffolding — so building on a well-known framework is the difference between an assistant that helps and one that guesses.

The mark

Two logos. One click, and they meet: the Shiny mark takes the middle, and React comes round into the tail of the swoosh.

That is the logo. Nothing about Shiny changed — React is just what the swoosh now ends in.

shinyreact

• Shiny UI infrastructure for React-based component rendering

• The Shiny server contains only reactive data computation
• The UI is a React client you own
• shinyreact ships zero UI components

With shinyreact, the Shiny server contains only reactive data computation, and the UI is a React client you own. shinyreact provides the bridge between the two and ships zero UI components itself.

Two frameworks, one reactive model: pure functional programming makes logic easy to reason about as apps scale up in complexity, and that is what makes both of these frameworks a joy to work in.

You build the whole UI from the ground up in React / TypeScript. It is an experimental package, for the brave few.

Old Faithful

The server we started with

app.R

x <- faithful$waiting

server <- function(input, output) {
  output$distPlot <- renderPlot({
    breaks <- seq(min(x), max(x), length.out = input$bin_count + 1)
    hist(x, breaks = breaks)
  })
}

input$bin_count → breaks → hist() → renderPlot()

Let’s re-imagine our Old Faithful app using shinyreact.

We can see the single input value bin_count being used to calculate breaks. That value is then fed into hist() with the specified breaks to produce a histogram of the data.

The same server, with shinyreact

app.R

x <- faithful$waiting

server <- function(input, output) {
  output$dist_data <- shinyreact::reactive_output({
    breaks <- seq(min(x), max(x), length.out = input$bin_count + 1)
    bins <- hist(x, breaks = breaks, plot = FALSE)
    bins[c("breaks", "counts")]
  })
}

input$bin_count → breaks → bins → reactive_output()

The reactive computation is unchanged. What has changed is the value sent by the server.

reactive_output() — a new concept!

• No 1:1 UI component needed
• Construct necessary data and send to client as JSON
• Let React display your data’s state in the UI

hist(x, plot = FALSE) creates a list containing breaks and counts. Now we just send the required data — that is the contracted shape the browser receives. Let React display your data’s state within the UI.

There is no directly corresponding UI component. This is a new concept! Where renderPlot() returns a regulated payload — HTML, or an image the plotOutput() on the other end knows how to place — reactive_output() returns nonregulated, raw data.

With this model, we are strongly encouraging the server to pass data directly to the front end. The server sends facts; React does presentation.

The UI we started with

app.R

ui <- bslib::page_sidebar(
  sidebar = bslib::sidebar(
    sliderInput(
      "bin_count",
      label = "Number of bins:",
      min = 1, max = 50,
      value = 30
    )
  ),
  plotOutput("distPlot")
)

That is the server. Now the other half of the same file.

Here is the UI we wrote in R: the page, the sidebar, the slider, the plot output. Every one of those is an R function whose job is to write HTML for you.

Watch what happens to it.

shinyreact UI

app.R

ui <- shinyreact::page_react_html("www/index.html")

That is the whole UI definition now. One line, pointing at the file the UI actually lives in.

So you are signing up for all of your UI inputs and outputs living in TypeScript.

Say that flat, and click.

Wait… what?

Let the fourth panel sit there. That is the question in the room.

And the honest answer is: you already do. Every hand that went up earlier was a hand that has written JavaScript. The question was never whether — it is whether you write it somewhere your tools can see it, or inside a quoted string where nothing can.

That is the big question in the room, so let’s take it now. Joe Cheng has always said Shiny authors shouldn’t need to write JavaScript — and I believe that still holds true.

Agents today have far more examples of mainstream React patterns than custom Shiny UI apps. I trust any frontier model to write React.js code better than I can. That narrow IDs-and-JSON contract makes the client boundary practical to review and maintain.

Your job is to describe your UI and review the result.

React

app.tsx

function App() {
  const [binCount, setBinCount] = useState(30);
  const bins = useMemo(() => bin_data(waiting, binCount), [binCount]);

  return (
    <main className="layout">
      <label htmlFor="bin_count">Number of bins:</label>
      <input id="bin_count" type="range" value={binCount}
             onChange={(e) => setBinCount(Number(e.target.value))} />
      <Histogram bins={bins} />
    </main>
  );
}

You have seen this one already — the React-only Old Faithful from section 02. One piece of state, one value derived from it, and the markup underneath.

Watch those two declarations at the top. Nothing else in this file is going to move.

shinyreact

www/ui.tsx

function App() {
  const [binCount, setBinCount] = useShinyInput<number>("bin_count", 30);
  const bins = useShinyOutputValue<HistData | null>("dist_data", null);

  return (
    <main className="layout">
      <label htmlFor="bin_count">Number of bins:</label>
      <input id="bin_count" type="range" value={binCount}
             onChange={(e) => setBinCount(Number(e.target.value))} />
      <Histogram bins={bins} />
    </main>
  );
}

Same component. The markup did not move — only the two lines that say where the values come from. Those two hooks are the whole API. useShinyInput reads and writes an input — just like useState, except the state comes from R or Python. useShinyOutputValue reads an output: R computes the value, React decides how it looks.

ui.tsx is built upon Shiny’s index.html escape hatch, but upgraded for React.

Compare line 2 to what we had in section 01. Getting a value out of the browser and into R was Shiny.setInputValue('card_clicked', …) — inside a string, flat green, unchecked by anything.

Here it is the same job, with a type on it. Your editor knows bin_count is a number. It will autocomplete it, and it will tell you when you get it wrong.

That is the whole trade: the JavaScript you were already writing, moved somewhere it can be read.

The data cycle

Browser · React const [binCount, setBinCount] =
useShinyInput("bin_count", 30) const bins =
useShinyOutputValue(
"dist_data", null)

{ "bin_count": 30 }

{ "dist_data": {…} }

Server · R / Python input$bin_count … <- reactive(…) output$dist_data <-
reactive_output({ … })

Left to right and back: the React side calls useShinyInput("bin_count", 30), and on the click that value goes over the wire as { "bin_count": 30 } — an id and a JSON value. That is what input$bin_count is on the server. The server is the app you already write: input$bin_count → reactive() → an output — except the output is reactive_output() in place of renderFn(). Its value comes back the same way, { "dist_data": {…} } — here breaks and counts — and useShinyOutputValue("dist_data", null) hands it to React as data.

Keep R / Python for data work and reactivity. Inputs still travel to the Shiny server; outputs now travel back as data, not HTML.

IDs and JSON are the contract: "bin_count" and "dist_data" are the same string on both sides, and they are the only thing the two sides share.

Old Faithful

#| '!! shinylive warning !!': |
#|   shinylive does not work in self-contained HTML documents.
#|   Please set `embed-resources: false` in your metadata.
#| standalone: true
#| components: [viewer]
#| viewerHeight: 1080

## file: app.R
# shinylive bundles `shinyreact` (and `brio`) into the render at build time,
# so nothing is installed at runtime. See CLAUDE.md.
library(shiny)
library(shinyreact)

# Base R ships the Old Faithful dataset; the Python servers read the same data
# from the faithful.csv exported next to this file.
x <- faithful$waiting

ui <- page_react_html("www/index.html")

server <- function(input, output, session) {
  # input$bin_count is NULL until the client's first
  # useShinyInput("bin_count", 30)
  # message arrives. Returning NULL leaves the React side on its "Loading…"
  # placeholder; req() would work too, but its silent error still reaches the
  # client. (Python's input.bin_count() raises a silent exception instead.)
  bin_count <- reactive(input$bin_count)

  output$dist_data <- reactive_output({
    n <- bin_count()
    if (is.null(n)) {
      return(NULL)
    }
    breaks <- seq(min(x), max(x), length.out = n + 1)
    bins <- hist(x, breaks = breaks, plot = FALSE)
    # I() keeps length-1 vectors as JSON arrays (n = 1) instead of scalars.
    list(breaks = I(bins$breaks), counts = I(bins$counts))
  })
}

shinyApp(ui, server)


## file: www/index.html
## type: text
<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Old Faithful — shinyreact</title>
    <!-- Shiny's and shinyreact's script/link tags are inserted here. It is a
         plain <meta> tag, so this file stays valid HTML. -->
    <meta name="shiny-dependency-placeholder" content="">
    <link rel="stylesheet" href="app.css" />
  </head>
  <body>
    <!-- The mount point. Visible until React takes over, so a slow bundle
         shows something other than a blank page. The styling goes on an inner
         div that React replaces - a class on #root itself would survive the
         mount, and `.placeholder`'s fixed height would then crop the app. -->
    <div id="root"><div class="placeholder">Loading…</div></div>
    <!-- `defer`, not a bare script: the shinyreact bundle in <head> is
         deferred, and deferred scripts run in document order. A non-deferred
         script here would run first and find no `window.shinyreact`. -->
    <script src="app.js" defer></script>
    <!-- shinylive runs this page in an iframe, so reveal never sees these keys.
         Hand them back via reveal's postMessage API. Identical in all three
         demos (apps/02-react-only/www/index.html, apps/00-old-faithful-trim/
         app.R) - change one, change all three. -->
    <script>
      // PageUp/PageDown is what most presenter remotes send and no widget wants
      // them, so they always go to the deck. A focused slider owns the arrows
      // and space, or advancing the deck would also drag the control.
      const deckKeys = { PageUp: 33, PageDown: 34 };
      const sharedKeys = { ArrowLeft: 37, ArrowUp: 38, ArrowRight: 39, ArrowDown: 40, " ": 32, Escape: 27 };
      addEventListener("keydown", (e) => {
        const widget = e.target instanceof Element &&
          e.target.closest("input, select, textarea, button, [contenteditable]");
        const keyCode = deckKeys[e.key] || (widget ? 0 : sharedKeys[e.key]);
        if (keyCode && parent !== window) {
          parent.postMessage(JSON.stringify({ method: "triggerKey", args: [keyCode] }), "*");
        }
      });
    </script>
  </body>
</html>


## file: www/app.css
## type: text
/* The only viewer of these two apps is a projector: they run in an iframe on a
   1920x1080 slide, at 1:1 with the deck's canvas. So the whole page is sized up
   from a laptop's defaults - everything below is in rem, and this is the one
   number that scales it. */
html {
  font-size: 26px;
}

body {
  margin: 0;
  padding: 0;
  background: #fff;
  font-family: system-ui, sans-serif;
  color: #1a1a1a;
}

.layout {
  display: flex;
  flex-wrap: wrap;
  gap: 1.5rem;
  /* Left-aligned and full-width, not a centred 60rem block: on the deck's
     1920px slide that left ~400px of white beside the sidebar that nothing
     collapses, and shrank the chart to something unreadable from the back. */
  margin: 1rem 0;
  padding: 0 1.5rem;
}

.sidebar {
  flex: 1 1 12rem;
  align-self: start;
  padding: 1rem;
  background: #f5f5f5;
  border-radius: 8px;
}

.sidebar label {
  display: block;
  margin-bottom: 0.5rem;
  font-size: 1.2rem;
}

/* A range input's thumb is a fixed ~16px whatever the font size, so it is
   scaled rather than sized; 2/3 width at 1.5x lands back on the full width. */
.sidebar input[type="range"] {
  width: 66.7%;
  transform: scale(1.5);
  transform-origin: left center;
}

.bin-count-value {
  display: block;
  margin-top: 1rem;
  font-size: 1.3rem;
  font-variant-numeric: tabular-nums;
  color: #666;
}

.panel {
  flex: 3 1 24rem;
}

/* The chart is width-driven (viewBox 620x320, `width: 100%`), so this cap is
   what keeps it inside the slide's height once the heading is above it. */
.panel svg {
  max-width: 1200px;
}

.panel h1 {
  margin: 0;
  font-size: 1.6rem;
}

.placeholder {
  display: grid;
  place-items: center;
  height: 20rem;
  border-radius: 8px;
  background: #f5f5f5;
  color: #888;
}

.recalculating {
  opacity: 0.6;
  transition: opacity 200ms;
}


## file: www/app.js
## type: text
const {
  React,
  ReactDOM,
  useShinyInput,
  useShinyOutputValue,
  useShinyOutputStatus,
  useShinyInitialized,
} = window.shinyreact;

const h = React.createElement;

// --- histogram chart -------------------------------------------------------

const W = 620;
const H = 320;
const M = { top: 16, right: 16, bottom: 52, left: 64 };
const PLOT_W = W - M.left - M.right;
const PLOT_H = H - M.top - M.bottom;

// Round `max` up to a friendly axis top, using a 1/2/5 × 10^n tick step.
function yTicks(max) {
  const raw = Math.max(max, 1) / 4;
  const mag = Math.pow(10, Math.floor(Math.log10(raw)));
  const step = [1, 2, 5, 10].map((m) => m * mag).find((s) => s >= raw);
  const top = Math.ceil(max / step) * step;
  const ticks = [];
  for (let v = 0; v <= top; v += step) ticks.push(v);
  return { top, ticks };
}

function xTicks(lo, hi) {
  const step = 10;
  const ticks = [];
  for (let v = Math.ceil(lo / step) * step; v <= hi; v += step) ticks.push(v);
  return ticks;
}

function Histogram({ bins }) {
  const { breaks, counts } = bins;
  const lo = breaks[0];
  const hi = breaks[breaks.length - 1];
  const { top, ticks } = yTicks(Math.max(...counts));

  const x = (v) => M.left + ((v - lo) / (hi - lo)) * PLOT_W;
  const y = (v) => M.top + PLOT_H - (v / top) * PLOT_H;

  return h(
    "svg",
    {
      viewBox: `0 0 ${W} ${H}`,
      width: "100%",
      role: "img",
      "aria-label": `Histogram of Old Faithful waiting times in ${counts.length} bins`,
    },
    // y gridlines + labels
    ticks.map((t) =>
      h(
        "g",
        { key: `y${t}` },
        h("line", {
          x1: M.left,
          x2: M.left + PLOT_W,
          y1: y(t),
          y2: y(t),
          stroke: "#e5e5e5",
        }),
        h(
          "text",
          {
            x: M.left - 10,
            y: y(t),
            textAnchor: "end",
            dominantBaseline: "middle",
            fontSize: 17,
            fill: "#666",
          },
          t,
        ),
      ),
    ),
    // bars
    counts.map((count, i) => {
      const x0 = x(breaks[i]);
      const x1 = x(breaks[i + 1]);
      return h("rect", {
        key: i,
        x: x0,
        width: Math.max(x1 - x0 - 1, 1),
        y: y(count),
        height: M.top + PLOT_H - y(count),
        fill: "#447099",
      });
    }),
    // x axis
    h("line", {
      x1: M.left,
      x2: M.left + PLOT_W,
      y1: M.top + PLOT_H,
      y2: M.top + PLOT_H,
      stroke: "#888",
    }),
    xTicks(lo, hi).map((t) =>
      h(
        "text",
        {
          key: `x${t}`,
          x: x(t),
          y: M.top + PLOT_H + 24,
          textAnchor: "middle",
          fontSize: 17,
          fill: "#666",
        },
        t,
      ),
    ),
    h(
      "text",
      {
        x: M.left + PLOT_W / 2,
        y: H - 8,
        textAnchor: "middle",
        fontSize: 18,
        fill: "#333",
      },
      "Waiting time to next eruption (minutes)",
    ),
    h(
      "text",
      {
        transform: `translate(16 ${M.top + PLOT_H / 2}) rotate(-90)`,
        textAnchor: "middle",
        fontSize: 18,
        fill: "#333",
      },
      "Frequency",
    ),
  );
}

// --- app -------------------------------------------------------------------

function App() {
  const initialized = useShinyInitialized();
  const [binCount, setBinCount] = useShinyInput("bin_count", 30);
  const bins = useShinyOutputValue("dist_data", null);
  const status = useShinyOutputStatus("dist_data");

  if (!initialized) return null;

  return h(
    "main",
    { className: "layout" },
    h(
      "aside",
      { className: "sidebar" },
      h("label", { htmlFor: "bin_count" }, "Number of bins:"),
      h("input", {
        id: "bin_count",
        type: "range",
        min: 1,
        max: 50,
        value: binCount,
        onChange: (e) => setBinCount(Number(e.target.value)),
      }),
      h("output", { htmlFor: "bin_count", className: "bin-count-value" }, binCount),
    ),
    h(
      "section",
      { className: "panel" },
      h("h1", null, "Hello Shiny!"),
      // Keep the chart mounted while the server recomputes — only show the
      // placeholder before the first value has ever arrived.
      bins
        ? h(
            "div",
            { className: status === "recalculating" ? "recalculating" : "" },
            h(Histogram, { bins }),
          )
        : h("div", { className: "placeholder" }, "Loading…"),
    ),
  );
}

const root = ReactDOM.createRoot(document.getElementById("root"));
root.render(h(App));

Testing

Test coverage at every hop

• Within the server — testServer() / test_server() · local_server
• Server → client — wire_tap
• Within the client — JS unit tests
• Confirm the client — features.md

The first hop is in-memory: the app’s server function runs, the reactive graph flushes, and you read the values back. No browser, no port, no waiting.

R has had shiny::testServer() for years. Shiny for Python shipped its own shiny.testserver.test_server() in 1.8.0, released 2026-09-12 — three days before this talk — plus a local_server pytest fixture: name it as a test argument and you get a started session for the app.py next to the test file.

def test_doubling_app(local_server):
    local_server.set_inputs(name="Ada", n=10)
    assert local_server.get_output("greeting") == "Hello, Ada!"

set_inputs() returns once the graph has settled, so the next line reads the result — no polling, no retry loop. That matters here because the React client is gone in this test: what you are asserting on is exactly the IDs-and-JSON contract the last section drew. The server half of a shinyreact app is testable without any of the client half existing.

The other three hops, in a line each: wire_tap asserts on the shinyreact messages crossing the websocket; the client’s own unit tests are the agent’s choice of JS runner; and features.md is a nested list of features you can read and other agents can confirm against.

That third hop is worth a beat. The JavaScript in section 01 had no tests, and could not have had any — you cannot unit-test a string. Getting it into a file is what put it on this list at all.

Future work

• Embed React components into existing apps
• Wrap shinyreact in your own package!

Incremental adoption makes it so you don’t have to port your whole application into React.js.

It also opens the door for helper packages down the road: wrap a component you have built in shinyreact and ship it as a package, the way bslib and friends ship theirs.

Today, everything will feel ad-hoc when writing shinyreact apps — that is the tradeoff of an experimental package.

shinyreact

• R / Python server processes data
• Build React client using AI agent
• Communicate using JSON and IDs
• posit-dev/shinyreact

Barret Schloerke

posit / Shiny Team

@schloerke

In the wild

None of this is theory any more. Over the summer one intern built a shelf of it.

Samuel Bharti.com

• Shiny summer ’26 intern
• Ph.D. candidate, UAB
• Computational biologist
• 10x Shiny apps, 5x packages
• posit-dev/shiny-showcase-bioinformatics

Samuel was our software engineering intern this summer — a computational biologist and a PhD candidate at UAB, previously at Genentech and Roche.

He spent the summer building bioinformatics Shiny apps, and the gallery is all of them in one place — that is the QR, and the heading finishes his address on its own if you wait a beat.

Summer Packages

• biobouncer – Is this a valid ID?

• bioclients – What do the sources say?

• biohttp – Move bytes, cache results

• biocohort – One study, one object

• plotomics – 17 GPU-accelerated charts

Five packages came out from under those apps, and each one answers a single question.

biobouncer — is this even an identifier? Fifty sources, offline first, and one shared conformance corpus across R, Python and JavaScript, so the three cannot disagree. It is on CRAN, PyPI and npm. bioclients — what do the sources say about it? Twenty-nine biological web services, one table shape. biohttp is what those clients ride on: every call returns a value rather than raising, with retry, a circuit breaker, and a cache that stores only the successes. biocohort — which subjects and samples are this study? The manifest, the subject table and every analysis output in one validated object, with species and assay as values in the data rather than types, so the same object serves any organism and any assay.

And plotomics — GPU-accelerated visualizations from one TypeScript core, wrapped three ways: npm for React, htmlwidgets for R, anywidget for Python. Headless factories, not React components, which is what lets one core serve all three. Seventeen chart types in the package; twenty-six of them on screen in the app you are about to see. Hold onto that one: it is what draws the app two slides from now.

Summer Bioinformatics Apps

• tahoe-explorer · 100.6M rows
  • Summaries push into DuckDB · source

• genescout · evidence review
  • A ranked, cited shortlist · source

• variant-reviewer · 23 cards
  • Public APIs, fanned out async · source

• gene-list-builder · 7 sources
  • Re-ranks as you tune the weights · source

• Plotomics Live · shinyreact
  • 1M WebGL points, one line of UI · source

Ten apps in the gallery; these are the five with public source. Every name here is a link — the app name goes to the deployment on Connect Cloud, the sub-bullet to the source — and each one is archived on Zenodo too, so there is a DOI to cite as well as an address. The README of this repo has all three columns.

Four of these are ordinary Shiny: shiny plus bslib, the UI written in R. That is the point — the last one is the only one that reaches for shinyreact, and it does it because the visualization demanded it.

Plotomics Live

1,000,000 transcripts on the GPU · 26 visualizations · 65+ reactive_output()

Xenium single-molecule transcripts. Every point is one mRNA molecule at the micrometre where it was detected in a breast cancer section — not a cell, not an embedding. The run found 42.6 million of them across a 313-gene panel, and a million of those are drawn here, on the GPU, from React.

Watch the loop. They arrive — a million points streamed as binary blobs and painted in one go. Hover one and you get the molecule under the cursor. Then zoom, and back out to the whole section: the red is tumour epithelium, the green is stroma, the teal is immune cells, and none of that structure is drawn by anything in R. R sent the numbers.

The ggplot2 toggle is right there in the same panel, and on this page it has to fall back to a subsample. That contrast is the argument.

Twenty-six visualizations, and the server publishes sixty-nine reactive_output() feeds to serve them: twenty-two data feeds React reads through useShinyOutputValue, twenty-eight ggplot2 PNGs for the classic side, and the rest stats and config.

Two things to say out loud about that:

• app.R is compute-only — one reactive_output() per visualization, and not one line of it is UI
• the entire UI, in R, is one line: page_react_html("www/index.html")

If there is time, the Xenium page is not even the biggest thing here. Another page draws a UMAP of 584,000 cells, and it ships as about seven megabytes of binary typed arrays — R to the browser to the GPU, rather than server-rendering the view. And because React owns the component, a new selection updates the data in place: the visualization is never re-mounted, so the GPU buffers are not reallocated on every click. That is the part you cannot get from an htmlwidget without writing the lifecycle yourself.

Samuel puts it better than I do: R stays the analysis engine, React becomes the visualization layer, and shinyreact removes what used to sit between them — the custom JS bindings, the manual message passing, the serialization.