I am writing this book as a text for others to read because that forces me to become explicit and explain all my learning outcomes more carefully. Please keep in mind that this text is not written by an expert but by a learner.
Text passages with content I am already familiar I have skipped. Section of the original text where I needed more in-depth knowledge I have elaborated and added my own comments resulted from my personal research.
Be warned! In spite of replicating most of the content this Quarto book may contain many mistakes. All the misapprehensions and errors are of course my own responsibility.
Content and Goals of this Book
This Quarto book collects my personal notes, trials and exercises of Engineering Production-Grade Shiny Apps by Colin Fay, Sébastien Rochette, Vincent Guyader and Cervan Girard (Fay et al. 2021).
I have some rudimentary {shiny} knowledge, but not sufficient enough for my big project of a dashboard for Reporters Without Borders data. “Engineering Production-Grade Shiny Apps” promises to fill my knowledge gap. See the following paragraph from the “Welcome” page:
If you are starting to read this book, we assume you have a working knowledge of how to build a small application using {shiny}, and want to know how to go one step further. In other words, you already have some knowledge about how {shiny} works, are able to build a small working application, and want to know how to build a serious, production-grade application that can be sent to production.
Text passages
Glossary
I am using the {glossary} package to create links to glossary entries.]
If you hover with your mouse over the double underlined links it opens an window with the appropriate glossary text. Try this example: Z-Score.
I have added many of the glossary entries when I was working through other books either taking the text passage of these books I was reading or via an internet recherche from other resources. Sometimes I have added the source of the glossary entry as an abbreviation or as an URL. Many definitions were provided by the KI provided within the search of my Brave browser.
If you fork the enginnering-shiny then the glossary will not work out of the box. Load down the glossary.yml
file from my glossary-pb GitHub repo, store it on your hard disk and change the path in the code chunk Listing / Output 1 accordingly.
In any case I am the only responsible person for the glossary text, especially if I have used text from other resources wrongly. Again: The main purpose of the glossary is to support my personal learning venture.
R Code and Datasets
During coding I am following the Tidyverse Style Guide. But for learning purposes I am trying to prefix all functions with the package name in the format :: (e.g., dplyr::filter()
) This is an overhead but supports me to understand which packages is responsible for which action.
Sometimes adding just the package name does not work. This is mostly the case when a generic function name like plot
is used by another package in a more specialized manner. In this case I will try to use the function of the package. If this doesn’t work too then I have to come back to the standard usage of base::library(<package-name>)
.
I am using the package name also for the default installation of base R. This wouldn’t be necessary but it helps me to understand where the base R functions come from. What follows is a list of base R packages of the system library included into every installation and attached (opened) by default:
- {base}: The R Base Package
- {datsets}: The R Datasets Package
- {graphics}: The R Graphics Package
- {grDevices}: The R Graphics Devices and Support for Colours and Fonts
- {methods}: Formal Methods and Classes
- {stats}: The R Stats Package
- {utils}: The R Utils Package
I am not using always the exact code snippets for my replications because I am not only replicating the code to see how it works but also to change the values of parameters to observe their influences.
When it is clear then I will follow the advice from Hadley Wickham:
When you call a function, you typically omit the names of data arguments, because they are used so commonly. If you override the default value of an argument, use the full name (tidyverse style guide).
I am not using code annotation because it disables code linking and does not show up correctly in the pop-up window generated with listing cross references.