Implement widget as Viewer-pane Shiny app

[keller-mark]

Should the user need to opt-in when creating the widget? Or should this be the only supported mechanism for rendering the widget? Or opt-out?

Should probably keep the plain htmlwidgets option for scenarios like widgets embedded in pkgdown sites where the widget needs to become static (no R process to run the Shiny server)

[keller-mark]

The problem is that this results in the R Console hanging while the widget runs... I don't think there is a way around this.

The shiny app can be launched via rstudioapi run as background job but then the app has no way to connect to the Viewer pane.

[keller-mark]

I think the solution is to allow the user to select between multiple scenarios when running the widget:

• mode shiny: plain htmlwidget to embed in other Shiny apps - bidirectional communication via calls Shiny.setInputValue - re-rendered via reactive environment
• mode static: plain htmlwidget (one-way communication) - no way to send data back to R process
  • R-to-JS comms only (via rerenders)
• mode gadget: shiny app in viewer pane (bidirectional communication), but the R Console will hang until the app is stopped
  • JS-to-R comms only (since R console is blocked)
• mode dynamic: htmlwidget with background websocket server that updates the R environment on messages - may only work in localhost settings - not confident that it would work with RStudioConnect or other remote settings like HPC clusters
  • user could manually pass the server host as a param
  • frontend can gracefully fall back to one-way communication if websocket messages fail to send to server