The solution simply masks shinyApp function from shiny package and introduces the print.shiny.appobj method which, depending on the mode in which notebook is executed, uses rcloud.web::rcw.result or returns an iframe to print the shiny.appobj.
Example that works in both: mini/shiny.html and in edit mode:
Unfortunately I had to bring back strong dependency on shiny - without it the 'shinyApp' function was not reliably masked by our implementation. I also looked if we can get rid of our override.shinyApp and use shinyApp from shiny package, but unfortunately this is not possible. So, unless there is a way to ensure that rcloud.shiny is always in front of shiny package on the namespace search path, we will need to go ahead with eagerly loading shiny package.
Supporting shiny apps in a cell required me to bring in some functions from htmlwidgets, for now these are copies (with some small changes). We could consider refactoring htmlwidgets.js so functions from there can be shared with rcloud.shiny, or making them generic enough so they are part of rcloud core. This however I would address with a separate issue to facilitate management/review of that change - as it will be cross-project change focusing on div classes and resizing and it will in fact add a new dependency to rcloud.shiny on rcloud.htmlwidgets...
Note: This builds on top of https://github.com/att/rcloud.shiny/pull/19 (this is why there are so many commits)
Actual implementation is in this commit: https://github.com/MangoTheCat/rcloud.shiny/commit/e0fea940c6847ec56f23fdd4250be1e7a432ca01
The solution simply masks shinyApp function from shiny package and introduces the print.shiny.appobj method which, depending on the mode in which notebook is executed, uses rcloud.web::rcw.result or returns an iframe to print the shiny.appobj.
Example that works in both: mini/shiny.html and in edit mode:
Dashboarding-shiny.html-AAA Tutorial Example in the cell.gist.zip
Unfortunately I had to bring back strong dependency on shiny - without it the 'shinyApp' function was not reliably masked by our implementation. I also looked if we can get rid of our override.shinyApp and use shinyApp from shiny package, but unfortunately this is not possible. So, unless there is a way to ensure that rcloud.shiny is always in front of shiny package on the namespace search path, we will need to go ahead with eagerly loading shiny package.
Supporting shiny apps in a cell required me to bring in some functions from htmlwidgets, for now these are copies (with some small changes). We could consider refactoring htmlwidgets.js so functions from there can be shared with rcloud.shiny, or making them generic enough so they are part of rcloud core. This however I would address with a separate issue to facilitate management/review of that change - as it will be cross-project change focusing on div classes and resizing and it will in fact add a new dependency to rcloud.shiny on rcloud.htmlwidgets...