In BioPharmSoftGrp/BaSS: PREP - Packages fRom tEmPlates

R Shiny App

By default the shiny app is created and linked to an R package. If the app does not need complex computation you can remove the call to load the library in the Global.R file. A couple important points:

@) ShinyUI.R - Contain several options to modify such as a) Application name, b) Author name, c) Contact info and d) release date. + Contains the sidebar object that setup the navigation bar on the left. + Contains the Body element which is the main content created via Modules.
+ To view modules refer to the Modules folder. @) Each tab should be created via modules. Each module is contained in the Modules folder and contains a ModuleNameUI.R and ModuleNameServer.R pair of files to create the UI and the server for each tab. @) Modules/DataAnalysisRunAnalysisServer.R - This file contains the example of how to call a function in the the R package. This approach would be the same to call any function in a package.

To launch the Shiny App, open the ShinyApp.R file, then click the button that says "Run App".

You may find the following functions in the PREP package helpful when you developing the Shiny app.

AddNewTabToApp( strTabName, vSubMenuItemNames ) - This function will add a new tab to the Shiny App. This function assumes that the working directory is the main directory of the Shiny app created by this package. This function creates a module file for the UI and the Server in the Modules directory of the app, it alters the ShinyUI.R file to insert the calls to modules so the tab is added to the UI.

Helpful packages

#. PREP - This packages was used to setup the GoNGCalcs and GoNGShiny projects. It can be installed with remotes::install_github("BioPharmSoftGrp/PREP") #. covr - Use to create a test coverage report with the following commands #. testthat - Package used for creating tests for your package.

Helpful Code and Code Snippets

From the PREP package, AddFunctionToPkg( strFunctionName, strPkgDir = "", strFunctionDescription = "" ) - Add a new function named strFunctionName to a package. This function creates a file names R/strFunctionName.R and adds a test function in the file tests/testthat/test-strFunctionName.R to be used with the testthat package.

To execute all tests in the project, execute the following code

#' @export
devtools::test()

Code snippets are very useful within R Studio. They allow you to type a short phrase and automatically insert a block of code.

Add code snippet by Clicking Tools-> Global Options -> Code-> Edit Snippets

```r snippet news3meth #' @name ${1} #' @title ${1} #' @description ${4:function description} #' @export ${1:MethodName} <- function( ${2:ClassObjName} ) { UseMethod( "${1}", ${2} ) } ${1}.default <- function( ${2} ) { stop( "The default method for ${1} is not defined.") }

snippet newcom r paste( paste( rep( "#", 100), collapse="" ), "." ) # ${0} #### r paste( paste( rep( "#", 100), collapse="" ), "." )

snippet header r paste( paste( rep( "#", 100), collapse="" ), "." ) # Program Name: ${1} # Author: J. Kyle Wathen # Description: # Category: # Usage: # Change History: r paste( paste( rep( "#", 100), collapse="" ), "." ) ```

Helpful Links

1. S3 Classes
2. R Packages Book
3. Mastering Shiny a. Introduction to Shiny modules b. Chapter 15 - Scaling Shiny Modules
4. Testing a. Testing R with testthat b. From R packages
5. Git Source Control
   a. Getting Started with Version Control b. Git for Windows c. Tortoise Git - Free Window shell program (runs in Windows explorer by Right clicking on a folder/file)]
6. R Studio Cheatsheet - There are several really good ones but the R Markdown, R Studio IDE and Shiny cheatsheets are really helpful for this project.

Style Guide

It is recommended to follow a style guide. One potential guide to use is the Biopharm Soft style guide. When developing code so that the style is consistent across different developers. A few key highlights are provided below.

If you are using source control such as GitHub it can be helpful to have guidelines. Please refer to the GitHub Section of the style guide when naming branches.

GitHub and Version Numbers

The section outlines the approach and rational for GitHub and the version numbers.

GitHub

Everyone creates feature/bug/documentation branches off of Dev.
Using IT to represent the users initials, branch names should follow a consistent naming pattern, like Feature-Add-XXX-IT, Test-CalcCHM-IT, Bug-XXX-IT. For example of Bob Smith (BS) was creating a branch to add a feature two add two numbers a good branch name would be Feature-Add2Numbers-BS.

Pull Requests (PRs) are against Dev so that when the are merged the issues close automatically. Then when a release is ready, eg whatever updates are going to be included have been merged into Dev, a PR is filled for Dev to be merged to master.

Branches are intended to be small and something a developer adds specific items to, then merges via a PR. A branch should be work that can be completed in a few hours/days and not weeks.

Once a PR for Dev->Master is executed, please make sure Dev and Master are at the same point. One way this can be done on GitHub by going to the Insights tab then clicking on Network.

A few details about the setup on GitHub:

@. A Dev branch has been created and set as the default. @. The option to "Automatically delete branches" when a PR is merged, is enabled. With this option enabled, when a PR is merged to Dev, the "from" branch is automatically deleted. By automatically deleting branches when a PR is merged, the remote repo (eg GitHub) should have fewer branches and be more clean. The auto delete feature does allow us to restore a delete branch if we need to. @. Since Dev is the default it will NOT be deleted when a PR from Dev->Master occurs.

Please note, the branch is ONLY deleted on the remote repo and is NOT deleted in the local repo. So if you were working on a branch Feature-123 and you file a PR from Feature-123 -> Dev when the PR is merged the Feature-123 branch is deleted on the remote, eg GitHub, but you still have a local copy on your computer. There are a few ways to delete a local branch.

Version Numbering

We will use the version numbers from semver.org

The following is the general version number explanation Version numbering from Sematic

• 0.0.x doesn't add features (mostly for bug fixes and documentation)
• 0.x.0 adds new features, but doesn't effect backwards compatibility.
• x.0.0 breaks backwards compatibility in some way.

Rationel for GitHub/Version Numbers

A few advantages of this approach:

• The version number is easy to explain and understand.
• The master branch is always the release
• When someone needs to create a branch it always come off of Dev (for all projects) and issues get closed when merge to Dev occur.
• Version numbers can quickly be explained.

This avoids us having to ask or remember what Dev-VX.X.X to create a branch off of or what issues have been closed when we have multiple people in different places working on things.

BioPharmSoftGrp/BaSS documentation built on April 2, 2021, 2:34 a.m.