Looking for detailed documentation on the render process for Quarto shiny documents (to help with a multi-page app design)

[jhelvy]

I'm building a survey platform leveraging Quarto shiny documents. It works just fine as is now, but I'm trying to understand the render process now to help me solve some issues I'm working on. We currently are using a lua filter to insert some js files, etc. before the ui renders to a static html page. But after the lua filter runs, we don't know what steps happen next. What does Quarto do with the rendered html page to then serve a shiny app? I just can't find any documentation on it. My understanding of the process is something like:

1. Render markdown & code chunks
2. Store content as AST
3. Run lua filter on AST
4. magic
5. Serve shiny app.

In case you're interested in why I want to know this, one thing I'm trying to do is see if it would be possible to split up that rendered static page into multiple static pages that I could then serve in the shiny server individually. The idea is to use a lua filter to split up the content into pages based on divs, save them as html pages, then replace the single static html page that would have been rendered with a sort of placeholder html page that the shiny server could then use to serve the individual pages into one-by-one. The whole goal of this is to keep the page content on the server side rather than client side. Right now with a single page design all of the content is available to the client in the single rendered html page - we're just using CSS and JS to hide and show it to appear like separate pages, but any user could just look at the source code and see everything. This is an issue for a survey platform that could contain things like completion codes at the end. I'm hopeful this approach might be solvable, but finding a solution depends on understanding what goes on in between the lua filter and a served shiny app.

[cscheid]

tl;dr: This is probably going to be too hard to do in practice.

But after the lua filter runs, we don't know what steps happen next. What does Quarto do with the rendered html page to then serve a shiny app? I just can't find any documentation on it.

Lua filters change the Pandoc AST. Pandoc produces an HTML output file from the resulting AST. Quarto runs a few postprocessors on the resulting file. In the case of Shiny documents, this is a little more involved because of the split between server and UI contexts that is described here: https://quarto.org/docs/interactive/shiny/index.html

But the main reason what you're trying to do is unlikely to work is this:

see if it would be possible to split up that rendered static page into multiple static pages that I could then serve in the shiny server individually.

The idea is to use a lua filter to split up the content into pages based on divs, save them as html pages, then replace the single static html page that would have been rendered with a sort of placeholder html page that the shiny server could then use to serve the individual pages into one-by-one

Quarto operates fairly strictly on a principle of "one .qmd file, one output file". There are exceptions to this, but they go in the opposite direction and are limited to book formats in postprocessing: after rendering each individual page, a book can be created by merging the different files into a single output .tex (or .epub, etc) file.

[jhelvy]

Thanks, I appreciate the detailed answer here. I kind of figured this might not be possible, and now I'm fairly sure that's the case. As a result, I actually already started working on a new architecture (this branch) for the surveydown project. The idea is now to still leverage Quarto to render a static html page of all of the survey content, and then in a traditional shiny app serve different parts of that html page depending on the survey "page" the user is on. So we're moving out of the Quarto shiny document format and instead just using a standard html output.

So far it's working surprisingly well. Just shiny::renderUI() on a given div in the server with a simple shiny::uiOutput() in the ui and it works. Also solves the issue I was concerned with as only the current page content is rendered from the server and accessible to the client. So respondents cannot see in the source code what is on other pages, because they're simply not rendered yet in the server.

In the end, this is looking like a much better overall architecture, but I don't think we would have ever come to it without first trying things with a Quarto shiny document.