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
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).
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.