Introduction

Published

2024-12-20

Using R package development practices will boost your productivity when building applications and make it easier for your collaborators. First, you will have a clear structure for your files. Second, others can easily share and use your work.

A guiding principle in this book comes from the Benjamin Franklin quote,

“A place for everything, everything in its place”

Packages help you

Do future you a favor.

Standardizing your projects helps anyone reading your code, especially future you. By structuring every Shiny app like an R package, you save time on setup (or re-orienting yourself to each project’s structure). Clear code is essential for Shiny applications in production, and using an R package is a common way to organize your code.¹

“a package [is] the fundamental unit of shareable, reusable, and reproducible R code.” - R Packages, 2ed

If you’re using RStudio or Positron, the package structure lets you access user-friendly tools for developing Shiny applications. These tools help you develop and test functions, run unit tests, store data, manage dependencies, and create documentation.

Packages help them

Assume someone else will read your code.

R packages provide a standardized way to enhance R’s capabilities, allowing others to install and use them in their R environment. When developing Shiny apps for production deployment, it’s important to remember that the code will likely be accessed and used by others.

To quote Marie Kondo, the de-cluttering expert,

“Ensuring that each one of your belongings has its own spot is the only way to maintain a tidy and clutter-free home. Clutter has nothing to do with what or how much you own – it’s the failure to put things back where they belong.”

R packages simplify sharing your work with colleagues by eliminating the need for them to determine where everything is located, how everything connects, and how it works.

What does it mean to ‘put something into production?’

‘Production’ usually means passing the code from your personal development environment into your company’s cloud-based server environment, which typically involves bundling your app in a structure that can be shared, installed, tested, and launched.

‘I think the easiest way to think about it for me is that we develop a model in one computational environment–think of this as maybe your laptop or maybe you work in a server environment–still, it’s in one place, and it turns out the software that you need to have installed there is about tuning, training, etc. Putting something into production is getting it out of that computational environment and successfully carrying it over to a new computational environment. For many people, this might be like a cloud computing environment. It might be some kind of server your organization has, and we need to take it, lift it, and then successfully have it working.’ - Julia Silge, What is ‘production’ anyway? MLOps for the curious (SatRdays London 2023))

I’ve added emphasis and edited this for clarity.

Packages are scalable

Great R packages solve common problems.

If you’ve developed R functions for tasks such as analysis, data visualization, or report generation, consider creating a package instead of using source() to load them. This approach will help you expand your understanding from specific use cases (e.g., “this code performs a specific task”) to a broader perspective (e.g., “this package can perform various tasks”).

The advantage of having a mental model for R packages is that you will often observe similarities in common problems. Developing packages that address and solve frequent issues in your workflow can lead to some of the most valuable and popular contributions, as seen with packages like datapasta and reprex`.

Packages to know

I highly recommend reading and bookmarking the Shiny articles and the sites for the core package development tools:

David Neuzerling has a great post on the benefits of structuring your project as a package↩︎