If you find issues while using VIEWpoly
, please, let us know through the issues tab in VIEWpoly
GitHub page. We would be glad if you also want to add another feature, for that, we provide the following guidelines.
First, you will need to have a Github account, fork our repository, and a copy of your viewpoly repository on your computer:
git clone https://github.com/your_user_id/viewpoly.git
If you are not familiar with git and GitHub, we suggest you check this tutorial.
VIEWpoly
was built following the modularized golem
framework, therefore, the easiest way to add new features to it is to create a new module. You can get a template for a module using:
::add_module(name = "new_feature",pkg = "/your/viewpoly/repository/directory/path/") golem
Create also a script named functions_new_feature.R
to store the functions you will use in your server
section.
If your new feature requires data that is not yet among the possible inputs listed in the mod_upload.R
, create a new box in this same module to add new input formats. Store the functions to read/convert the input files in the functions_upload.R
. To be used in another module, the added data need to be listed as one of the returned values of the mod_upload server function. The new data will also need to be added as a new item in the viewpoly object (see here).
In the case you want to add a new linkage map or QTL mapping software to display the graphics and tables that are already implemented, you will need also to create a new box in mod_upload.R
to input the software output data and create a prepare_AddedSoftware
function in the functions_upload.R
script (see example here) to convert the added software output format to viewpoly object.
Make sure to include an example dataset to be displayed when the app starts. The example included in the package needs to have a small size to be able to be submitted to CRAN, but it is important to make it available through a link (like these) a complete dataset to users explore all results.
All functions included in functions_*.R
scripts should contain roxygen comments to build documentation even if the function will not be available for users (exported). New features also need to be described in the VIEWpoly
vignette. Submit the vignette updates here.
It is important to add testthat
tests for all functions included in the functions_* scripts in R/.
For some of the graphics, checking just the server functions are not efficient, then we use vdiffr
package to convert the output images to SVG and then match expected and current (check example here).
To test the reactive functions, we use the shinytest
package to create snapshots of the app to be compared. However, differences between expected and current seems to be very sensitive to the machine it runs. To overcome this, we created two shinytest
files, one that runs the test just for the basic interface and does not break the Github actions (github_actions_tests.R), and another to be run just locally (local_tests.R). Feel free to include tests for the added features in these files.
Submit your modifications to our Github repository through a pull request. We will evaluate the modifications and adapt VIEWpoly
version and DESCRIPTION file.