Export shiny as a single page

htmlwidget
plotly

#1

I would like to have a semi-interactive single file that I can share that would not require running a server. For example, if you wanted to generate a plot, but have the ability to change the source data. Shiny is great for these applications, but you need the server component for it to work. Is it possible to export Shiny as single standalone document?

Since the short answer is "no", maybe a better question is if there is some alternative method. For example, I can export plotly graphs with htmlwidgets::saveWidget(). Those can be quite elaborate and comprehensive. However, they are still limited. For example, if you wanted to have a simple option to change colors, it does not seem possible to add a drop-down menu to switch between them.


#2

There are widgets other than Plotly that support htmlwidgets::saveWidget(); here's a gallery of them! Many—but not all—of those widgets support Crosstalk, which allows widgets to talk to each other with or without Shiny. If you have a look on the Crosstalk site, you can see some examples of how it'd work in a standalone page without Shiny.

That said, anything reactive other than the widgets themselves—such as general purpose sliders to modify plots—is going to require Shiny, unless you decide to build a custom htmlwidget to handle such behaviour (or fork an existing one!). There's no option to make any old Shiny app run without Shiny AFAIK; they need it to do what they do.

EDIT: actually, looking at Crosstalk examples a bit further, it does allow you to add controls that can filter content (but not do more general purpose computation, like a total rerender). Unless you need R code to rerun whenever your plots update, this might be what you want!


#3

That is very helpful.

I noticed there is manipulateWidget, which looked very promising. Then I saw this at the end of the vignette:

manipulateWidget uses Shiny, so it does not work in a “normal” Rmarkdown document. If one uses the function in a code chunck, the htmlwidget will be outputed with the default values of the parameters and there will be no interface to modify the parameters.


#4

It might help if you can give a more precise description of the sort of interaction you're hoping for. It's possible that what you want isn't doable with the existing tools, but it's also possible that people might be able to suggest workarounds/approximations with a clearer specification of the goals.