Shiny is the go-to web application framework for R users due to its flexibility and ease of use. Although R developers have been quick to adopt generative AI tools into their daily workflows, there are unique challenges to using these tools for Shiny development. Developing R code follows a linear process: the code is written in the order that it will run. Shiny code has no such requirement because the code will behave in response to user inputs. In the past this has posed a challenge for AI code assistants; however generative AI tools have reached a level of maturity that they can now supercharge R Shiny development. This post will discuss our experiences leveraging GitHub Copilot for a code-free Shiny development project.
Plan: Use Co-pilot with the bigger picture in mind
R developers are able incorporate GitHub Copilot through RStudio integration and can start with a short prompt to generate the first lines of code with logic flowing from there. Copilot is typically pretty good at guessing what you want to do next with fairly simple prompts; however, our experience with Shiny is that it is a good idea to provide Copilot with a more comprehensive and non-technical overview of the application’s purpose and layout. For example, the following prompt will generate a simple app that evaluates whether a number is prime.
#' This is an R shiny app that checks whether a number is prime or not. #' The user can specify the number to check in two ways. #' First, the user can enter the number, and then #' click a button to trigger the calculation. #' Second, the user can click another button that lets the app #' randomly generate a number between 1 and 1000, and then check #' whether the number is prime or not.
However, few Shiny applications are so simple. Most mature Shiny programming involves multiple files and modules. For example, many developers choose to include ui.R, server.R, and global.R. More advanced applications may include dozens of modules stored as individual R scripts. These are often supplemented by HTML and CSS files for improving the user interface. GitHub Copilot pulls information from all open files in the IDE, and strategically including additional program files can provide the AI with important context and provide more appropriate suggestions. For many IDEs, this means you should keep the most relevant files open in other tabs. When developing in RStudio, make sure to have a plan about the file structure of your Shiny app, create an R project, and enable indexing project files with GitHub Copilot. This will provide access to the project files and build the contextual information Copilot needs to be most effective.
Care: The nuances of reactive elements
GitHub Copilot does not always give the most correct suggestion for complicated reactivities, so generative AI has not completely replaced the skilled developer. In our experience, Copilot does not always have the best judgement when it comes to picking reactive values or reactive expressions in the server code. In such cases, the developer may need to provide in-line prompts, or write R code themselves, to correctly create reactive elements. For example, the server code below looks fine, but the number check will stop working once the user clicks the reset button.
server <- function(input, output) {
output$result <- renderText({
if (is.numeric(input$number)) {
if (input$number %% 2 == 0) {
paste(input$number, "is an even number.")
} else {
paste(input$number, "is an odd number.")
}
} else {
"Please enter an integer."
}
})
observeEvent(input$reset, {
output$result <- renderText("")
})
}
To fix this error, we can include a more nuanced instruction about reactive values to correctly implement the server code: [block classes=”has-grey-background-colour”]
# Use a reactiveVal named "number_to_check". # When the user changes the "number" input, set the value of "number_to_check" to the numeric value of the "number" input. # When the user clicks the "Reset" button, set the value of "number_to_check" to NULL. Also clear the "number" input.
Effort: The magic of R Shiny domain knowledge
GitHub Copilot has an incredible ability to learn based on the context provided by the user in the form of text and code examples. Most issues with Copilot’s suggestions are that much of the R code used in Shiny is unique to Shiny. Copilot often does not have the context necessary for it to easily generate some kinds of code, including:
- Reactive values and expressions
- Observers
- Modules and namespaces
In a Shiny module, when UI elements are generated from the server code, namespacing should be explicit, as opposed to implicit namespacing in other parts of the server code. The prompt below helps make sure that code generated by CoPilot adheres to this principle: [block classes=”has-grey-background-colour”]
#' If UI elements are defined in the module server,
#' then the `session$ns()` function is needed to namespace them when passing the "id" parameter.
#' For example, if you define a text input in the module server as
#' `textInput(session$ns("gender"), "Gender")`, you can refer to the
#' input in the module server as `input$gender`.
Provided with adequate domain knowledge through appropriate prompts, Copilot’s suggestions can become much more accurate in the R Shiny context. The key to efficient use of GitHub Copilot in Shiny development is to invest in efforts to gather and organize a tested prompt library. These prompts can be developed to efficiently instruct the AI in the nuances of Shiny syntax and will boost the productivity of your Shiny developers when deployed. Our team of talented consultants at ProCogia have been at the vanguard of developing generative AI tools for use in Shiny development. We have found that tools like GitHub Copilot have accelerated our internal work and that with a little bespoke refining and development, these tools can take your team to the next level. We can offer you both generic and customized prompt databases that will enable your team to spin up timely dashboards so you can make quick data-driven decisions about your business.
