Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modularize code #11

Open
mlbendall opened this issue Jul 19, 2016 · 4 comments
Open

Modularize code #11

mlbendall opened this issue Jul 19, 2016 · 4 comments

Comments

@mlbendall
Copy link
Collaborator

Check out this article.
http://shiny.rstudio.com/articles/modules.html

In order to work together effectively, and to make PathoStats as flexible as possible, we are going to need to write code that can be easily plugged into the PathoStats core. In the above article, the Rstudio folks have written up one possible way to do it, and I think it makes sense. I'm also open to other ideas.

I've started to do this for the Relative Abundance module, and I put an idea of what this might look like in this branch: https://github.com/mani2012/PathoStat/blob/newRAplots/R/relativeAbundance.R

My proposal is that each "top level" (relative abundance, diversity, differential expression, etc.) will live in its own file (within R/ directory). The module will be loaded into the shiny server. If you want to make additional tabs within that module, I would suggest that you create these as sub modules of the top-level module. This way all the code as well as UI elements for a tab/module are in one place and should be easy to change in the future.

@ecastron
Copy link
Collaborator

It makes sense to me. It'd be easier as we move forward and add more features. Going to give it a try with the longitudinal tab

@anfederico
Copy link
Contributor

anfederico commented Jun 2, 2018

Here is a great barebones example of how one would modularize the code base.

https://github.com/daattali/advanced-shiny/tree/master/split-code

I think this project would benefit from this solution as the codebase is quite large. Some of the UI views are already modularized so maybe the best focus would be on making the server.R file modular (It's 2400 lines of code).

For example, each tab in the web-application would have a specific ui/server file.
ui_upload.R
server_upload.R
And so on for each tab...

Just a suggestion though, I know a big change like this takes considerable effort, but I would be willing to help! I'm sure it will benefit the project in terms of longevity.

@mlbendall
Copy link
Collaborator Author

I already began to modularize the code, it just never made it into master. See the diversity module branch.

I'd suggest putting both the UI and server functions into the same file, and call the functions uploadModule and uploadModuleUI.

@anfederico
Copy link
Contributor

anfederico commented Jun 4, 2018

Ah nice, looks good. What else needs to be done to merge? is the testing going smoothly?

Edit: I see, it's far behind the master.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants