Introduction

Published

2024-07-03

The guiding principles throughout this book are:

Code files should be easy to find
Work should be easy to check and share

The principles above are heavily influenced by the Benjamin Franklin quote,

“A place for everything, everything in its place”

And the de-cluttering methods popularized by Marie Kondo,

“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.”

Packages help you

Do future ‘you’ a favor.

The first and obvious benefit to structuring your Shiny app as an R package is that it simplifies file and folder management. If every Shiny app project you develop is structured as an R package, it removes the time you spend manually creating directories (or re-orienting yourself to each project’s structure).

If you’re using Posit Workbench, the R package structure will give you access to a well-designed IDE for Shiny applications. Posit Workbench has tools to help develop and debug functions, create and run unit tests, store internal and external data, manage dependencies, and write help files and long-form documentation.

Packages help them

Assume someone else will read your code.

It’s safe to assume the code used to build Shiny apps being deployed to a production environment will be seen (and hopefully used) by others. R packages make sharing your hard work with your colleagues easier because it removes their need to figure out where everything is, how it all fits together, and how it all (hopefully) works.

R packages are designed for others to install and use in their R environment. Hence, packages are a standardized way of extending R’s capabilities by adding new functionality (like developing Shiny apps!).

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

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.

Making an effort to write clear and simple code is a courtesy to whoever reads your code next (which is typically future you). Clear and straightforward code is especially important for Shiny applications destined for deployment in a production environment. The standardized and widely accepted way to organize code in R is as an R package.¹

Packages are scalable

Great R packages solve common problems.

Suppose you use R to perform analyses, design data visualizations, or build and run reports. If you currently use source() to load any utility functions to perform this work, I suggest putting those functions in a package. Doing this will help extend your mental model from the specific use cases (i.e., “X code performs task Y”) to a model for their more general uses (i.e., “X package performs tasks like Y”).

The beauty of an R package mental model is that you’ll inevitably notice the similarities across common problems. Creating packages that define and solve common problems in your workflow can sometimes be some of the most popular/valuable contributions (see 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↩︎