- Show code
+Show code
+
```{.python}
from shiny import App, render, ui
import pandas as pd
@@ -261,7 +369,7 @@ It's also possible to share reactive objects across sessions.
This can be potentially dangerous since one users activity could impact another's, but also quite useful in combination [`reactive.file_reader`](../api/reactive.file_reader.qmd) and [`reactive.poll`](../api/reactive.poll.qmd) to create a reactive data source that's only polled once, no matter how many users are connected.
:::
-## Sessions
+### Sessions
Shiny apps have an object that represent a particular user's [session](../api/Session.html).
This object is useful for a variety of more advanced tasks like [sending messages to the client](../api/Session.html#shiny.Session.send_custom_message) and [serving up session-specific data](../api/Session.html#shiny.Session.dynamic_route).
diff --git a/docs/express-introduction.qmd b/docs/express-introduction.qmd
deleted file mode 100644
index f424b7e4..00000000
--- a/docs/express-introduction.qmd
+++ /dev/null
@@ -1,38 +0,0 @@
----
-title: Introduction
-editor:
- markdown:
- wrap: sentence
----
-
-Up until now, these docs have focused on Shiny _Express_, which compared to Shiny _Core_, offers a simpler way to learn and write basic apps.
-The simplicity that Express offers, however, can come at the cost of reduced flexibility and maintainability.
-In other words, Express is quicker to get started with, but can eventually lead to code that's more difficult for others (or your future self) to read, maintain, and extend.
-Fortunately, it's straightforward to [transition](express-to-core.qmd) from Express to Core since many of the foundations (i.e., [components](ui-overview.qmd), [reactivity](reactive-foundations.qmd), etc.) are the same.
-
-Compared to Express, Core enforces a more structured approach that requires more initial effort to use.
-However, we believe that investment pays off on projects where increased flexibility and maintainability are important.
-This is because Shiny Core enforces:
-
-1. **Decoupling of UI and server**. Decoupling forces you to separate concerns in such a way that it's easier refactor and reason about a large amount of code.
-2. **Functional programming**. Express encourages a more imperative (less functional) style, which can be easier to write, but also harder to read. This is especially true when you need to create [reusable extractions](express-in-depth.qmd##expressify).
-3. **More explicit UI**. Express has magical defaults that make things simpler, but can also mask what's actually going on behind-the-scenes, and offers less opportunities to customize behavior.
-
-The next article illustrates how these downsides can be mitigated to some extent in Express with some advanced tooling.
-However, if you feel yourself reaching for these tools, it might be time to switch to Core.
-If you're already convinced that Shiny Core is right for your app, feel free to skip ahead to the [transitioning](express-to-core.qmd) article.
-
-::: callout-note
-### Shiny Core is a superset of Express
-
-Shiny Core is a superset of Express, meaning that anything you can do in Express, you can also do in Core.
-The reverse is not true, however.
-For example [Shiny Modules](modules.qmd) are not currently supported in Express.
-:::
-
-::: callout-note
-### Shiny Core is more mature
-
-Shiny Express is still relatively new, and is still being actively developed.
-As such, you can expect the Express experience to keep improving over time.
-:::
diff --git a/docs/express-or-core.qmd b/docs/express-or-core.qmd
new file mode 100644
index 00000000..ca2fe836
--- /dev/null
+++ b/docs/express-or-core.qmd
@@ -0,0 +1,267 @@
+---
+title: Choosing a syntax
+editor:
+ markdown:
+ wrap: sentence
+---
+
+Now that you are familiar with [the differences between Shiny Express and Shiny Core](express-vs-core.qmd), you might be wondering how to choose between them.
+
+In this article, we'll suggest some guidelines, but it's important to note that there are not many hard and fast rules.
+There is a lot of overlap between the capabilities of the two syntaxes, so feel free to choose whichever feels more natural and comfortable for you.
+
+Shiny Express is designed to get you up and running as quickly as possible.
+It's also designed to let you author your app with a minimum of boilerplate.
+As a result, it really shines in the early stages of both the learning journey and the lifecycle of an app.
+
+Compared to Express, Core enforces a more structured approach that requires more initial effort to use.
+However, that investment has its own payoff.
+
+The bulk of the rest of this article will focus on the advantages of Shiny Core.
+This isn't because we think it's better, but because Shiny Express's advantages---being more approachable and more concise---are fairly self-evident, while Shiny Core's advantages are more subtle.
+
+## Maintainability
+
+**Consider using Shiny Core if you are building a large or long-lived app.**
+
+The most important difference between the two syntaxes is that Express allows you to intermingle UI and server code, while Core requires you to separate them.
+The separation that Core requires can feel inconvenient while adding features to your app, as each new output requires you to edit two different places in your `app.py` file.
+
+But for larger and longer-lived apps, Shiny Core's more opinionated approach becomes an advantage.
+It is much easier to add, remove, or relocate pieces of your UI when all of its code is in one place, with no server code to confuse things. Similarly, when you're trying to understand the relationship between a reactive calculation and some outputs, it's much easier to do so when you don't have intermingled UI code in the way.
+
+At the [bottom of this page](#appendix), you'll find a Shiny Core version of the [dashboard app from the Essentials section](user-interfaces.qmd#all-together-now){target="_blank"} of this guide.
+Compare their respective source code, and consider:
+
+* Which version makes the structure of the UI more obvious?
+* Which version would make you more confident in moving UI elements around?
+* Which version makes it easier to understand the reactive calcs and outputs?
+
+## Feature set
+
+**Consider using Shiny Core if you need to use Shiny Modules or dynamic UI.**
+
+At this time, Shiny Core's functionality is a superset of Express, meaning that anything you can do in Express, you can also do in Core.
+The reverse is not true, however.
+
+Most importantly, [Shiny Modules](modules.qmd) are supported in Shiny Core but not (yet) in Shiny Express. Shiny Modules are extremely useful for organizing large apps into smaller, more manageable pieces, and are also a mechanism for reusing Shiny application logic.
+
+Shiny Core also has `ui.insert_ui()` and `ui.remove_ui()` functions, which is a way to imperatively add or remove UI elements from the app at any time.
+Despite being available in `shiny.express.ui`, these functions do not currently work well with Shiny Express. The same goes for `ui.modal_show()`.
+
+## Maturity
+
+**Consider using Shiny Core if you care more about maturity and stability than convenience.**
+
+Given its longer history, Shiny Core is naturally more mature than Shiny Express in both syntax and implementation.
+
+We've carefully designed the Shiny Express syntax, and hope not to have to make breaking changes to it.
+However, we don't know what we don't know, and it's possible that user feedback or our own testing will someday require us to make significant changes.
+
+Similarly, we are constantly testing Shiny Express, but as of this writing, it has not has as much real-world use as Shiny Core.
+Therefore, with Shiny Core, you are less likely to encounter bugs.
+
+## Familiarity to R users
+
+**Consider using Shiny Core if you are an R user who is already familiar with Shiny.**
+
+While Shiny Core is not a literal translation of Shiny for R, it is much closer to it than Shiny Express.
+The UI/server separation, the nested UI function calls, the matching of output IDs to render functions, are all going to feel very natural to experienced Shiny for R app authors.
+
+
+
+## Appendix
+
+The following is the dashboard application from the Essentials section of this guide, rewritten using Shiny Core.
+Compare it to [the original](user-interfaces.qmd#all-together-now).
+
+::: {.column-page-right}
+
+```{shinylive-python}
+#| standalone: true
+#| components: [editor, viewer]
+#| layout: vertical
+#| viewerHeight: 800
+import faicons as fa
+import plotly.express as px
+from shinywidgets import output_widget, render_plotly
+
+from shiny import App, reactive, render, req, ui
+
+# Load data and compute static values
+tips = px.data.tips()
+bill_rng = (min(tips.total_bill), max(tips.total_bill))
+
+ICONS = {
+ "user": fa.icon_svg("user", "regular"),
+ "wallet": fa.icon_svg("wallet"),
+ "currency-dollar": fa.icon_svg("dollar-sign"),
+ "gear": fa.icon_svg("gear")
+}
+
+app_ui = ui.page_sidebar(
+ ui.sidebar(
+ ui.input_slider("total_bill", "Bill amount", min=bill_rng[0], max=bill_rng[1], value=bill_rng, pre="$"),
+ ui.input_checkbox_group("time", "Food service", ["Lunch", "Dinner"], selected=["Lunch", "Dinner"], inline=True),
+ ui.input_action_button("reset", "Reset filter"),
+ ),
+ ui.layout_columns(
+ ui.value_box(
+ "Total tippers",
+ ui.output_ui("total_tippers"),
+ showcase=ICONS["user"],
+ showcase_layout="left center",
+ ),
+ ui.value_box(
+ "Average tip",
+ ui.output_ui("average_tip"),
+ showcase=ICONS["wallet"],
+ showcase_layout="left center",
+ ),
+ ui.value_box(
+ "Average bill",
+ ui.output_ui("average_bill"),
+ showcase=ICONS["currency-dollar"],
+ showcase_layout="left center",
+ ),
+ fill=False,
+ ),
+ ui.layout_columns(
+ ui.card(
+ ui.card_header("Tips data"),
+ ui.output_data_frame("table"),
+ full_screen=True,
+ ),
+ ui.card(
+ ui.card_header(
+ "Total bill vs tip",
+ ui.popover(
+ ICONS["gear"],
+ ui.input_radio_buttons(
+ "scatter_color", None,
+ ["none", "sex", "smoker", "day", "time"],
+ inline=True,
+ ),
+ title="Add a color variable",
+ placement="top",
+ ),
+ class_="d-flex justify-content-between align-items-center"
+ ),
+ output_widget("scatterplot"),
+ full_screen=True,
+ ),
+ ui.card(
+ ui.card_header(
+ "Tip percentages",
+ ui.popover(
+ ICONS["gear"],
+ ui.input_radio_buttons(
+ "tip_perc_y", "Split by:",
+ ["sex", "smoker", "day", "time"],
+ selected="day",
+ inline=True,
+ ),
+ title="Add a color variable",
+ ),
+ class_="d-flex justify-content-between align-items-center",
+ ),
+ output_widget("tip_perc"),
+ full_screen=True,
+ ),
+ col_widths=[6, 6, 12],
+ ),
+ title="Restaurant tipping",
+ fillable=True,
+)
+
+def server(input, output, session):
+
+ # --------------------------------------------------------
+ # Reactive calculations and effects
+ # --------------------------------------------------------
+
+ @reactive.calc
+ def tips_data():
+ bill = input.total_bill()
+ idx1 = tips.total_bill.between(bill[0], bill[1])
+ idx2 = tips.time.isin(input.time())
+ return tips[idx1 & idx2]
+
+ @reactive.effect
+ @reactive.event(input.reset)
+ def _():
+ ui.update_slider("total_bill", value=bill_rng)
+ ui.update_checkbox_group("time", selected=["Lunch", "Dinner"])
+
+ # --------------------------------------------------------
+ # Outputs
+ # --------------------------------------------------------
+
+ @render.ui
+ def total_tippers():
+ return tips_data().shape[0]
+
+ @render.ui
+ def average_tip():
+ d = tips_data()
+ req(d.shape[0] > 0)
+ perc = d.tip / d.total_bill
+ return f"{perc.mean():.1%}"
+
+ @render.ui
+ def average_bill():
+ d = tips_data()
+ req(d.shape[0] > 0)
+ bill = d.total_bill.mean()
+ return f"${bill:.2f}"
+
+ @render.data_frame
+ def table():
+ return render.DataGrid(tips_data())
+
+
+ @render_plotly
+ def scatterplot():
+ color = input.scatter_color()
+ return px.scatter(
+ tips_data(),
+ x="total_bill",
+ y="tip",
+ color=None if color == "none" else color,
+ trendline="lowess"
+ )
+
+ @render_plotly
+ def tip_perc():
+ from ridgeplot import ridgeplot
+ dat = tips_data().copy()
+ dat.loc[:, "percent"] = dat.tip / dat.total_bill
+ yvar = input.tip_perc_y()
+ uvals = dat[yvar].unique()
+
+ samples = [
+ [ dat.percent[dat[yvar] == val] ]
+ for val in uvals
+ ]
+
+ plt = ridgeplot(
+ samples=samples, labels=uvals, bandwidth=0.01,
+ colorscale="viridis", colormode="row-index"
+ )
+
+ plt.update_layout(
+ legend=dict(orientation="h", yanchor="bottom", y=1.02, xanchor="center", x=0.5)
+ )
+
+ return plt
+
+app = App(app_ui, server)
+
+## file: requirements.txt
+ridgeplot
+```
+
+:::
diff --git a/docs/express-vs-core.qmd b/docs/express-vs-core.qmd
new file mode 100644
index 00000000..062ad6ad
--- /dev/null
+++ b/docs/express-vs-core.qmd
@@ -0,0 +1,262 @@
+---
+title: Express vs. Core
+editor:
+ markdown:
+ wrap: sentence
+---
+
+Shiny is one framework with two different syntax options: _Shiny Express_ and _Shiny Core_.
+Up until now, these docs have focused on Shiny Express.
+In this section, we'll dig into the differences between the two, and why you might choose one or the other.
+
+Don't worry, though.
+There is an enormous amount of overlap between the two, and the vast majority of apps will be well served by either Shiny Express or Shiny Core.
+
+And if you do decide to switch, the process is relatively straightforward---especially in the direction of Express to Core, as the latter supports a superset of the former's capabilities. We go into more detail on this in the [transitioning](express-to-core.qmd) article.
+
+## Background
+
+Shiny for Python was unveiled in 2022 with a single syntax option, which we now call Shiny Core.
+It drew inspiration from the [Shiny framework for R](https://shiny.posit.co/), which has been around for over a decade and is used by hundreds of thousands of data scientists around the world.
+Our goal was to make Shiny Core feel Pythonic, as opposed to a literal port of Shiny for R, but carry over the same core principles and tradeoffs.
+
+In January 2024, we introduced Shiny Express as a second syntax option.
+Express is built on top of Core, and is designed to be extremely easy to write, while preserving most of the power and flexibility of Shiny.
+
+## Differences between Express and Core
+
+The major differences between Shiny Express and Core are the following:
+
+- Slightly different import statements
+- Different organization of UI and server code
+- Implicit vs. explicit placement of outputs
+- Different syntax for UI containers
+
+Let's examine each of these in more detail.
+
+### Import statements
+
+A Shiny Core app file usually contains an import statement like:
+
+```python
+from shiny import App, reactive, render, ui
+```
+
+In Shiny Express, you'll instead see:
+
+```python
+from shiny import reactive
+from shiny.express import input, render, ui
+```
+
+Note that both import `ui` and `render`, but from different places.
+While Express's `shiny.express.ui` has almost all of the same UI functions as Core's `shiny.ui`, their function signatures often differ slightly, to reflect Express's different usage patterns.
+And the `render` functions---well actually, they are identical right now, but we're planning to add some Express-specific features to the `shiny.express.render` versions in the near future.
+
+Meanwhile, the `reactive` module is unchanged between Core and Express, as the two modes share the same reactive foundations.
+
+Finally, notice that Express also imports `input` from `shiny.express`.
+This isn't needed in Core, because the `input` object is passed into the server function as an argument.
+Since Express has no server function, we made it an attribute of `shiny.express`.
+
+### Organization of UI and server code
+
+**Every Shiny Core app file has a UI section, and a server section;** the two are separate and distinct.
+
+The UI section consists of a single (potentially very long and deeply nested) expression, stored as a variable named `app_ui` by convention.
+The object this produces is actually straight up HTML, which is sent to the browser when it first loads the app.
+
+The server section is a function, named `server` by convention, that always takes the arguments `input`, `output`, and `session`.
+This function contains render functions and reactive functions, which are used to update the UI in response to user input.
+
+You can think of the UI section as a template, with `ui.output_xx()` calls as placeholders for outputs, and the server section as the instructions for how to populate those outputs.
+
+```{shinylive-python}
+#| standalone: true
+#| components: [editor, viewer]
+#| layout: vertical
+# Core
+from shiny import ui, render, reactive, App
+from datetime import datetime
+
+app_ui = ui.page_fixed(
+ ui.h1("Title"),
+ ui.output_code("greeting"),
+)
+
+def server(input, output, session):
+ @reactive.Calc
+ def time():
+ reactive.invalidate_later(1)
+ return datetime.now()
+
+ @render.code
+ def greeting():
+ return f"Hello, world!\nIt's currently {time()}."
+
+app = App(app_ui, server)
+```
+
+**In Shiny Express, there isn't this hard distinction** between UI and server.
+
+Instead, everything coexists as top-level code in the app file: input components, layout directives, outputs (including their rendering logic), and reactive functions.
+
+Also, you aren't forced to combine your UI into a single complex object.
+You can use multiple UI objects, and they will be combined together by the framework.
+
+```{shinylive-python}
+#| standalone: true
+#| components: [editor, viewer]
+#| layout: vertical
+# Express
+from shiny import ui, render, reactive, App
+import shiny.express
+from datetime import datetime
+
+ui.h1("Title")
+
+@reactive.Calc
+def time():
+ reactive.invalidate_later(1)
+ return datetime.now()
+
+@render.code
+def greeting():
+ return f"Hello, world!\nIt's currently {time()}."
+```
+
+Again, notice how `greeting` in this app does _not_ have a corresponding call to `output_code("greeting")`.
+This is because in Shiny Express, `render` functions automatically add an output to the page---no need to do it manually.
+
+##### Core advantages
+
+- Because the UI structure is kept separate from the server, it is easier to read, reorder, and restructure. This advantage grows as app UIs grow larger.
+- Explicit server function declaration gives us a natural place to put code that should only execute at startup (top level) versus for each session (server function body). In contrast, in Express, all of the code in the app file is executed for each session.
+
+##### Express advantages
+
+- It's nice for beginners not to have to learn about the difference between UI and server.
+- Avoids having to write code in two different places for a single output, and having to make the IDs match up.
+- No need to write nested function declarations (i.e. functions inside the server function), which can be surprising to Python programmers.
+
+### Implicit vs. explicit placement of outputs
+
+For an output to appear in a Shiny app of any type, the framework needs to know two things: where it should go in the UI, and how it should be rendered.
+
+In Shiny Core, this is done in two separate steps. In the UI, you create a placeholder for the output, using a function like `ui.output_plot("plot1")`. Then, in the server, you create a rendering function, using a decorator like `@render.plot`, and name the function the same as the placeholder, like `def plot1():`.
+
+In Shiny Express, this is done in a single step. You create a rendering function, using a decorator like `@render.plot`, and name the function however you like (as long as it's unique). The framework automatically creates a placeholder in the UI where the function is defined.
+
+##### Core advantages
+
+- Moving an output from one place in the UI to another is as simple as moving the corresponding placeholder function.
+- The `ui.output_xx()` functions currently have some additional arguments that allow you to customize the output's behavior, like enabling plot brushing (with `ui.output_plot("plot1", brush=True)`). This is not as natural in Express, though workarounds do exist---see the [next article](express-in-depth.qmd).
+
+##### Express advantages
+
+- No need to carefully match the names of placeholders and rendering functions.
+
+### Different syntax for UI containers
+
+Broadly speaking, there are two kinds of UI components in Shiny: _container components_, which, as the name suggests, can contain other components, and _non-container components_, which cannot.
+(You can also think of the UI as a tree data structure: container components have children, while non-container components are leaf nodes in the tree.)
+
+Here are some examples of container components:
+
+- [`ui.sidebar()`](../layouts/sidebars.qmd)
+- [`ui.card()`](../layouts/panels-cards.qmd#content-divided-by-cards)
+- [`ui.layout_columns()`](../layouts/arrange.qmd#grid-layouts)
+- `ui.div()`
+
+Here are some examples of non-container components:
+
+- [`ui.input_text()`](../components/inputs/text-box.qmd)
+- [`ui.output_plot()`](../components/outputs/plot-matplotlib.qmd)
+
+**In Shiny Core, to put a component inside of a container, you nest the function calls,** like `ui.sidebar(ui.input_text())`.
+
+::: {.column-page-right}
+```{shinylive-python}
+#| standalone: true
+#| components: [editor, viewer]
+#| layout: vertical
+# Core
+from shiny import ui, render, App
+
+app_ui = ui.page_sidebar(
+ ui.sidebar(
+ ui.input_text("txt_in", "Type something here:"),
+ open="always",
+ ),
+ ui.card(
+ ui.output_code("result"),
+ )
+)
+
+def server(input, output, session):
+ @render.code
+ def result():
+ return f"You entered '{input.txt_in()}'."
+
+app = App(app_ui, server)
+```
+:::
+
+By contrast, **in Shiny Express, container components like `ui.sidebar()` are _context managers_**, and used via `with` statements.
+Their child components go within the `with` block.
+
+::: {.column-page-right}
+```{shinylive-python}
+#| standalone: true
+#| components: [editor, viewer]
+#| layout: vertical
+# Express
+from shiny import render, App
+from shiny.express import input, ui
+
+with ui.sidebar():
+ ui.input_text("txt_in", "Type something here:")
+
+with ui.card():
+ @render.code
+ def result():
+ return f"You entered '{input.txt_in()}'."
+```
+:::
+
+##### Core advantages
+
+- Passing children as arguments is beautifully simple and robust from a programming perspective.
+- Containers and non-containers behave very similarly (in fact, non-containers act no different than containers with no children).
+- All of the Core UI components are simple value-returning functions, without side effects. This makes them easy to compose, reuse, refactor, inspect, and test.
+
+##### Express advantages
+
+- The `with` block syntax is slightly more readable, as it depends only on indentation and not on parentheses and commas.
+- You can put arbitrary Python code inside `with` blocks, including loops, conditionals, import statements, function definitions, reactive functions, and output rendering functions. (In Core, you are limited to Python expressions that generate UI.)
+
+::: {.callout-note}
+In unusual situations, you might want to create HTML content that doesn't use context managers. HTML tag functions, like `div()` and `span()` can actually be used as context managers or as regular functions, so the following are equivalent:
+
+```{shinylive-python}
+#| standalone: true
+#| components: [editor, viewer]
+#| layout: vertical
+# Express
+from shiny.express import ui
+
+with ui.div():
+ with ui.pre(style="background-color: #eff;"):
+ "Hello!"
+
+ui.div(
+ ui.pre(
+ "Hello!",
+ style="background-color: #eff;",
+ ),
+)
+```
+
+More complex component functions, such as `ui.sidebar()` and `ui.card()`, can only be used as context managers in Shiny Express.
+
+:::
diff --git a/docs/modules.qmd b/docs/modules.qmd
index 77ea20bc..e0cdbfb8 100644
--- a/docs/modules.qmd
+++ b/docs/modules.qmd
@@ -20,7 +20,7 @@ Python modules are a generic way to organize objects in a namespace, while Shiny
::: callout-warning
### Shiny core only
-Modules are not currently supported in [Shiny Express](express-introduction.qmd) apps.
+Modules are not currently supported in [Shiny Express](express-vs-core.qmd) apps.
:::
diff --git a/docs/overview.qmd b/docs/overview.qmd
index 82c8313c..74180a8b 100644
--- a/docs/overview.qmd
+++ b/docs/overview.qmd
@@ -50,7 +50,7 @@ This example demonstrates the basic mechanics behind Shiny apps:
* Outputs are created by decorating a function with `@render.*`.
* Inside a `render` function, `input` values can be read [reactively](#reactivity).
* When those `input` values change, Shiny knows how to minimally re-render output.
-* This example happens to use `shiny.express` which, [compared to core Shiny](express-introduction.qmd), reduces the amount of code required.
+* This example happens to use `shiny.express` which, [compared to core Shiny](express-vs-core.qmd), reduces the amount of code required.
### Components {#components}
diff --git a/docs/ui-customize.qmd b/docs/ui-customize.qmd
index f3864da5..9d38c3e1 100644
--- a/docs/ui-customize.qmd
+++ b/docs/ui-customize.qmd
@@ -224,7 +224,7 @@ app = App(app_ui, None, static_assets=app_dir / "www")
```
::: callout-note
-Serving local files is currently only supported with [Shiny Core](express-introduction.qmd) (i.e., it doesn't yet work with Express).
+Serving local files is currently only supported with [Shiny Core](express-vs-core.qmd) (i.e., it doesn't yet work with Express).
:::
diff --git a/docs/ui-overview.qmd b/docs/ui-overview.qmd
index 0fbc3c6b..97c08678 100644
--- a/docs/ui-overview.qmd
+++ b/docs/ui-overview.qmd
@@ -203,8 +203,8 @@ See the [layout gallery](/layouts) for an overview of available layout mechanism
### Page layouts
A special type of layout is the page layout, which is used to start a new UI.
-In [Shiny Express](express-introduction.qmd), the page layout is implicit, and automatically inferred from the top-level UI components.
-In [Shiny Core](express-introduction.qmd), the page layout is explicit, meaning that the UI starts with a page layout component (e.g. `ui.page_fluid()`, `ui.page_sidebar()`, etc).
+In [Shiny Express](express-vs-core.qmd), the page layout is implicit, and automatically inferred from the top-level UI components.
+In [Shiny Core](express-vs-core.qmd), the page layout is explicit, meaning that the UI starts with a page layout component (e.g. `ui.page_fluid()`, `ui.page_sidebar()`, etc).
::: {.column-body-outset-right .panel-tabset .panel-pills .border-0 .justify-content-center}
diff --git a/docs/user-interfaces.qmd b/docs/user-interfaces.qmd
index 66c5bff3..ab2e2aa2 100644
--- a/docs/user-interfaces.qmd
+++ b/docs/user-interfaces.qmd
@@ -233,7 +233,7 @@ with ui.popover(title="Popover title"):
```
-### Altogether now
+### All together now
Let's put it all together to create a dashboard for exploring restaurant tipping data.
@@ -277,27 +277,27 @@ with ui.layout_columns(fill=False):
with ui.value_box(showcase=ICONS["user"]):
"Total tippers"
- @render.ui
+ @render.express
def total_tippers():
- return tips_data().shape[0]
+ tips_data().shape[0]
with ui.value_box(showcase=ICONS["wallet"]):
"Average tip"
- @render.ui
+ @render.express
def average_tip():
d = tips_data()
- req(d.shape[0] > 0)
- perc = d.tip / d.total_bill
- return f"{perc.mean():.1%}"
+ if d.shape[0] > 0:
+ perc = d.tip / d.total_bill
+ f"{perc.mean():.1%}"
with ui.value_box(showcase=ICONS["currency-dollar"]):
"Average bill"
- @render.ui
+ @render.express
def average_bill():
d = tips_data()
- req(d.shape[0] > 0)
- bill = d.total_bill.mean()
- return f"${bill:.2f}"
+ if d.shape[0] > 0:
+ bill = d.total_bill.mean()
+ f"${bill:.2f}"
with ui.layout_columns(col_widths=[6, 6, 12]):
diff --git a/include-in-header.html b/include-in-header.html
index cb16b4dd..12a6b77d 100644
--- a/include-in-header.html
+++ b/include-in-header.html
@@ -75,7 +75,7 @@
function addWhatsShinyExpressTooltip() {
const tooltipContents = `Shiny Express is a new, streamlined way to write a Shiny app.
Shiny Core refers to the original, functional Shiny syntax, which is still a great way to write Shiny apps.
- Read more
`
+ Read more
`
const tooltipDisplay = `What's the difference?`
@@ -131,6 +131,6 @@
learn Shiny.
- What about Shiny Core?
+ What about Shiny Core?