Closed jaeddy closed 6 years ago
Thanks for the link to the training slides. I'm reviewing them now. Very helpful. Template for modules: https://gist.github.com/jcheng5/c09a2449c0a94c8f498c4a68a416bc3b
Would we make the modules to follow the figure taxonomy? We can reuse the modules and have multiple links (with different analysis aims and titles) to each one.
iatlas-demo/ ├── global.R ├── modules │ ├── Scatter plot module.R │ ├── Boxplot family module.R │ ├── Bargraphs module.R │ └── Kaplan-Meier module.R | |-------etc.R ├── server.R └── ui.R
Thanks, @Gibbsdavidl — the module template also looks handy.
I was thinking that we'd try to follow the figure taxonomy, but with the modules themselves more organized by "bioapplication" as @vthorsson describes it. Something along these lines:
iatlas-demo/
├── global.R
├── modules
│ ├── samplegroupsmodule.R
│ ├── featurecorrelationmodule.R
│ ├── geneexplorermodule.R
│ └── survivalmodule.R
├── widgets
│ ├── scatterplot.R
│ ├── boxplot.R
│ ├── barplot.R
│ ├── mosaicplot.R
│ └── kmplot.R
├── server.R
└── ui.R
Such that functions for creating different widgets
can be used by multiple modules
. Not sure if this is the best approach, but trying to minimize duplicated code.
Modifying the structure a bit, based on @vthorsson's question about loading data...
Instead of "widgets", we'd have a place where we store re-usable "functions" (I think I've also seen these named as "helpers" — either would be fine with me).
iatlas-demo/
├── global.R
├── modules
│ ├── samplegroupsmodule.R
│ ├── featurecorrelationmodule.R
│ ├── geneexplorermodule.R
│ └── survivalmodule.R
├── functions
│ ├── scatterplot.R
│ ├── boxplot.R
│ ├── barplot.R
│ ├── mosaicplot.R
│ ├── kmplot.R
│ ├── load_data.R
│ └── utils.R
├── server.R
└── ui.R
@andrewelamb: below is a more detailed plan for mapping our existing content into the proposed reorganization. For this pass, the focus should be more on setting up the overall file/folder structure, not on consolidating code (which we'll try to tackle with #2). In other words, it's fine for now if code is duplicated in multiple files, as long as we can get the overall app to work.
This can probably be a single branch/PR, but might require multiple commits for any debugging that comes up...
iatlas-demo/
├── global.R
├── modules
│ ├── cellcontentmodule.R
│ ├── immuneinterfacemodule.R
│ ├── featurecorrelationmodule.R
│ └── survivalmodule.R
├── functions
│ ├── heatmap.R
│ ├── boxplot.R
│ ├── barplot.R
│ ├── kmplot.R
│ ├── load_data.R
│ └── utils.R
├── server.R
└── ui.R
modules
cellcontentmodule.R
:
panel-ui-cellcontent.R
-> cellcontent_UI(...)
panel-server-cellcontent.R
-> cellcontent(...)
immuneinterfacemodule.R
:
panel-ui-clonaldiversity.R
-> immuneinterface_UI(...)
panel-server-clonaldiversity.R
-> immuneinterface(...)
featurecorrelationmodule.R
:
panel-ui-corrheatmap.R
-> featurecorrelation_UI(...)
panel-server-corrheatmap.R
-> featurecorrelation(...)
survivalmodule.R
:
panel-ui-survivalcurve.R
-> survival_UI(...)
panel-server-survivalcurve.R
-> survival_UI(...)
functions
load_data.R
(copy/paste for now):
global.R
::load_<x>_data(...)
for each 'x'utils.R
(copy/paste for now):
global.R
::getVars(...)
global.R
::getNiceName(...)
global.R
::buildDataFrame_corr(...)
global.R
::buildDataFrame_surv(...)
The functions are still in globals for now, but can be removed at any point.
This is finished
See slides here for more details: https://github.com/daattali/shiny-training-rstudioconf-2018/blob/master/slides/05-modules.pdf
Basically, instead of
...we'd want something more like this:
Each module script would include a UI and server function — e.g.,
cellcontent_module_UI()
andcellcontent_module()
incellcontentmodule.R
. Module scripts would then be sourced inglobal.R
and functions used inui.R
andserver.R