Thank you all for the recommendations. It is very interesting to know how other developers are using Shiny.
I have been working on a Shiny application and I did some decisions on code that are similar to your recommendations: Separate app into three files to reflect the MVC (Model, View, Controller): -* AllUtilities.R *file has functions which do data processing (completely independent from interface), these function have unit tests. - *ui.R* file has only one function that builds the interface. I avoid using any kind of function call that depends on some data. - *server.R* file has only one function that controls/modifies the interface and does function calls of AllUtilities.R or user level functions. Tyler Smith, I have used Reference Class to store data throughout the execution of the application. It works very well with Shiny but it may be problematic for using this type outside the application. Best, Welliton On Wed, Mar 29, 2017 at 2:41 PM Tyler Smith <[email protected]> wrote: On Wed, Mar 29, 2017, at 11:23 AM, Martin Morgan wrote: > On 03/29/2017 09:32 AM, Vladimir Kiselev wrote: > > Hi Wellinton, > > > > As far as I know if you wrap you shiny stuff into an R function that should > > be enough. Then you can provide both non-interactive and interactive > > functions and the user can choose what to run. > > > > - Allow for interactive use integrated in an R session -- during an R > session, the app is used for particularly graphically-oriented > operations, and the end result of app usage is made available to the R > session for subsequent processing. This kind of workflow, not > necessarily in shiny, is possible in epivisr and RCyjs; > interactiveDisplay was developed with this idea in mind This is what I have done in flowPloidy: https://github.com/Bioconductor-mirror/flowPloidy The user passes a list of FlowHist objects (an extension of flowFrame) to the shiny app. Within the app they can correct the model fitting. After exiting the app, the updated objects are returned for further work at the R console. Shiny uses some non-standard evaluation techniques (I think that's the right description?) that make it a little tricky to keep track of the appropriate environments when updating objects. I posted a short toy example to stack overflow that shows how I dealt with that: http://stackoverflow.com/questions/17263627/shiny-r-application-that-allows-users-to-modify-data/38835957#38835957 This requires using the `<<-` operator to pass a value up one level of nesting within the app function. It doesn't directly modify the global environment though, so should be acceptable. I can't figure out any other way to deal with this. I started out providing functions to complete the entire process from the command line. But the shiny interface is so much more convenient and powerful that I rarely use the command line functions anymore, even for debugging. Best, Tyler _______________________________________________ [email protected] mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel [[alternative HTML version deleted]] _______________________________________________ [email protected] mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
