implement suggestions from code review: make links refer to pkgdown websites if they exist, clarify usage of .data; improve overall consistency

Author: paleolimbot

vignettes/ggplot2-in-packages.Rmd

@@ -31,7 +31,7 @@ mpg_drv_summary <- function() {
 mpg_drv_summary()
 ```
 
-If you use ggplot2 functions frequently, you may wish to import one or more functions from ggplot2 into your `NAMESPACE`. If you use [roxygen2](https://cran.r-project.org/package=roxygen2), you can include `#' @importFrom ggplot2 <one or more function names>` in any roxygen comment block (this will not work for datasets like `mpg`).
+If you use ggplot2 functions frequently, you may wish to import one or more functions from ggplot2 into your `NAMESPACE`. If you use [roxygen2](https://cran.r-project.org/package=roxygen2), you can include `#' @importFrom ggplot2 <one or more object names>` in any roxygen comment block (this will not work for datasets like `mpg`).
 
 ```{r}
 #' @importFrom ggplot2 ggplot aes geom_bar coord_flip
@@ -47,14 +47,13 @@ mpg_drv_summary <- function() {
 mpg_drv_summary()
 ```
 
-Even if you use many ggplot2 functions in your package, it is unwise to use ggplot2 in `Depends` or import the entire package into your `NAMESPACE`. Using ggplot2 in `Depends` will attach ggplot2 when your package is attached, which includes when your package is tested. This makes it difficult to ensure that others can use the functions in your package without attaching it (i.e., using `::`). Similarly, importing all 450 of ggplot2's exported objects into your namespace makes it difficult to separate the responsibility of your package and the responsibility of ggplot2, in addition to making it difficult for readers of your code to figure out where functions are coming from!
+Even if you use many ggplot2 functions in your package, it is unwise to use ggplot2 in `Depends` or import the entire package into your `NAMESPACE` (e.g. with `#' @import ggplot2`). Using ggplot2 in `Depends` will attach ggplot2 when your package is attached, which includes when your package is tested. This makes it difficult to ensure that others can use the functions in your package without attaching it (i.e., using `::`). Similarly, importing all 450 of ggplot2's exported objects into your namespace makes it difficult to separate the responsibility of your package and the responsibility of ggplot2, in addition to making it difficult for readers of your code to figure out where functions are coming from!
 
 ## Using `aes()` and `vars()` in a package function
 
 To create any graphic using ggplot2 you will probably need to use `aes()` at least once. If your graphic uses facets, you might be using `vars()` to refer to columns in the plot/layer data. Both of these functions use non-standard evaluation, so if you try to use them in a function within a package they will result in a CMD check note:
 
 ```{r}
-#' @importFrom ggplot2 ggplot aes geom_bar coord_flip
 mpg_drv_summary <- function() {
   ggplot(ggplot2::mpg) + 
     geom_bar(aes(x = drv)) + 
@@ -75,12 +74,11 @@ There are three situations in which you will encounter this problem:
 - You have the column name as a character vector.
 - The user specifies the column name or expression, and you want your function to use the same kind of non-standard evaluation used by `aes()` and `vars()`.
 
-If you already know the mapping in advance (like the above example) you should use the `.data` pronoun from [rlang](https://cran.r-project.org/package=rlang) to make it explicit that you are referring to the `drv` in the data and not some other variable named `drv` (which may or may not exist elsewhere).
+If you already know the mapping in advance (like the above example) you should use the `.data` pronoun from [rlang](https://rlang.r-lib.org/) to make it explicit that you are referring to the `drv` in the layer data and not some other variable named `drv` (which may or may not exist elsewhere). To avoid a similar note from the CMD check about `.data`, use `#' @importFrom rlang .data` in any roxygen code block (typically this should be in the package documentation as generated by `usethis::use_package_doc()`).
 
 ```{r}
-#' @importFrom rlang .data
 mpg_drv_summary <- function() {
-  ggplot(mpg) + 
+  ggplot(ggplot2::mpg) + 
     geom_bar(aes(x = .data$drv)) + 
     coord_flip()
 }
@@ -89,39 +87,40 @@ mpg_drv_summary <- function() {
 If you have the column name as a character vector (e.g., `col = "drv"`), use `.data[[col]]`:
 
 ```{r}
-#' @importFrom rlang .data
-col_summary <- function(data, col) {
-  ggplot(mpg) + 
+col_summary <- function(df, col) {
+  ggplot(df) + 
     geom_bar(aes(x = .data[[col]])) + 
     coord_flip()
 }
 
 col_summary(mpg, "drv")
 ```
 
-To use the same kind of non-standard evaluation used by `aes()` and `vars()`, use `{{ col }}` to pass the unevaluated expression the user typed in `col` to `aes()`.
-
-<!-- this uses development rlang, which is not yet released -->
+If the column name or expression is supplied by the user, you can also pass it to `aes()` or `vars()` using `{{ col }}`. This tidy eval operator captures the expression supplied by the user and forwards it to another tidy eval-enabled function such as `aes()` or `vars()`.
 
-```{r, eval=FALSE}
-col_summary <- function(data, col) {
-  ggplot(mpg) + 
+```{r, eval = (packageVersion("rlang") >= "0.3.4.9003")}
+col_summary <- function(df, col) {
+  ggplot(df) + 
     geom_bar(aes(x = {{ col }})) + 
     coord_flip()
 }
 
 col_summary(mpg, drv)
 ```
 
-To summarise, if you know the mapping or facet specification is `col` in advance, use `aes(.data$col)` or `vars(.data$col)`. If `col` is a variable that contains the column name as a character scalar, use `aes(.data[[col]]` or `vars(.data[[col]])`. If you would like the behaviour of `col` to look and feel like `aes()` and `vars()`, use `aes({{ col }})` or `vars({{ col }})`.
+To summarise:
+
+- If you know the mapping or facet specification is `col` in advance, use `aes(.data$col)` or `vars(.data$col)`. 
+- If `col` is a variable that contains the column name as a character vector, use `aes(.data[[col]]` or `vars(.data[[col]])`.
+- If you would like the behaviour of `col` to look and feel like it would within `aes()` and `vars()`, use `aes({{ col }})` or `vars({{ col }})`.
 
-You will see a lot of other ways to do this in the wild, but the syntax we use here is the only one we can guarantee will work in the future! In particular, don't use `aes_()` or `aes_string()`, as they are deprecated and may be removed in a future version. Finally, don't skip the step of creating a data frame and a mapping to pass in to `ggplot()` or its layers! You will see other ways of doing this in the wild, but these may rely on undocumented behaviour and can fail in unexpected ways.
+You will see a lot of other ways to do this in the wild, but the syntax we use here is the only one we can guarantee will work in the future! In particular, don't use `aes_()` or `aes_string()`, as they are deprecated and may be removed in a future version. Finally, don't skip the step of creating a data frame and a mapping to pass in to `ggplot()` or its layers! You will see other ways of doing this, but these may rely on undocumented behaviour and can fail in unexpected ways.
 
 ## Best practices for common tasks
 
 ### Using ggplot2 to visualize an object
 
-ggplot2 is commonly used in packages to visualize objects (e.g., in a `plot()`-style function). For example, a package might define an S3 object that represents the probability of various discrete values:
+ggplot2 is commonly used in packages to visualize objects (e.g., in a `plot()`-style function). For example, a package might define an S3 class that represents the probability of various discrete values:
 
 ```{r}
 mpg_drv_dist <- structure(
@@ -134,7 +133,7 @@ mpg_drv_dist <- structure(
 )
 ```
 
-Many S3 objects in R implement a `plot()` method, but it is unrealistic to expect that a single `plot()` method can provide the visualization every one of your users is looking for. It is useful, however, to provide a `plot()` method as a visual summary that users can call to understand the essence of an object. To satisfy all your users, we suggest writing a function that transforms the object into a data frame (or a `list()` of data frames if your object is more complicated). A good example of this approach is [ggdendro](https://cran.r-project.org/package=ggdendro), which creates dendrograms using ggplot2 but also computes the data necessary for users to make their own. For the above example, the function might look like this:
+Many S3 classes in R have a `plot()` method, but it is unrealistic to expect that a single `plot()` method can provide the visualization every one of your users is looking for. It is useful, however, to provide a `plot()` method as a visual summary that users can call to understand the essence of an object. To satisfy all your users, we suggest writing a function that transforms the object into a data frame (or a `list()` of data frames if your object is more complicated). A good example of this approach is [ggdendro](https://cran.r-project.org/package=ggdendro), which creates dendrograms using ggplot2 but also computes the data necessary for users to make their own. For the above example, the function might look like this:
 
 ```{r}
 discrete_distr_data <- function(x) {
@@ -147,11 +146,10 @@ discrete_distr_data <- function(x) {
 discrete_distr_data(mpg_drv_dist)
 ```
 
-In general, users of `plot()` call it for its side-effects: it results in a graphic being displayed. This is different than the behaviour of a `ggplot()`, which is not rendered unless it is explicitly `print()`ed. Because of this, ggplot2 defines its own generic `autoplot()`, a call to which is expected to return a `ggplot()` (with no side effects).
+In general, users of `plot()` call it for its side-effects: it results in a graphic being displayed. This is different than the behaviour of a `ggplot()`, which is not displayed unless it is explicitly `print()`ed. Because of this, ggplot2 defines its own generic `autoplot()`, a call to which is expected to return a `ggplot()` (with no side effects).
 
 ```{r}
 #' @importFrom ggplot2 autoplot
-#' @importFrom rlang .data
 autoplot.discrete_distr <- function(object, ...) {
   plot_data <- discrete_distr_data(object)
   ggplot(plot_data, aes(.data$value, .data$probability)) +
@@ -170,7 +168,7 @@ plot.discrete_distr <- function(x, ...) {
 }
 ```
 
-It is considered bad practice to implement an S3 generic like `plot()`, or `autoplot()` if you don't own the S3 object, as it makes it hard for the package developer who does have control over the S3 to implement the method themselves. This shouldn't stop you from creating your own functions to visualize these objects!
+It is considered bad practice to implement an S3 generic like `plot()`, or `autoplot()` if you don't own the S3 class, as it makes it hard for the package developer who does have control over the S3 to implement the method themselves. This shouldn't stop you from creating your own functions to visualize these objects!
 
 ### Creating a new theme
 
@@ -204,7 +202,7 @@ mpg_drv_summary2 <- function() {
 
 ### Testing ggplot2 output
 
-We suggest testing the output of ggplot2 in using the [vdiffr](https://cran.r-project.org/package=vdiffr) package, which is a tool to manage visual test cases (this is one of the ways we test ggplot2). If changes in ggplot2 or your code introduce a change in the visual output of a ggplot, tests will fail when you run them locally or on Travis. To use vdiffr, make sure you are using [testthat](https://cran.r-project.org/package=testthat) (you can use `usethis::use_testthat()` to get started) and add vdiffr to `Suggests` in your `DESCRIPTION`. Then, use `expect_doppleganger(<name of plot>, <ggplot object>)` to make a test that fails if there are visual changes in `<ggplot object>`.
+We suggest testing the output of ggplot2 in using the [vdiffr](https://cran.r-project.org/package=vdiffr) package, which is a tool to manage visual test cases (this is one of the ways we test ggplot2). If changes in ggplot2 or your code introduce a change in the visual output of a ggplot, tests will fail when you run them locally or on Travis. To use vdiffr, make sure you are using [testthat](https://testthat.r-lib.org/) (you can use `usethis::use_testthat()` to get started) and add vdiffr to `Suggests` in your `DESCRIPTION`. Then, use `vdiffr::expect_doppleganger(<name of plot>, <ggplot object>)` to make a test that fails if there are visual changes in `<ggplot object>`.
 
 ```r
 test_that("output of ggplot() is stable", {
@@ -230,7 +228,7 @@ theme_custom <- function(...) {
 mpg_drv_summary() + theme_custom()
 ```
 
-Generally, if you add a method for a ggplot2 generic like `autoplot()`, ggplot2 should be in `Imports`. If for some reason you would like to keep ggplot2 in `Suggests`, it is possible to register your generics only if ggplot2 is installed using `vctrs::s3_register()`. If you do this, you should copy and paste the source of `vctrs::s3_register()` into your own package to avoid adding a [vctrs](https://cran.r-project.org/package=vctrs) dependency.
+Generally, if you add a method for a ggplot2 generic like `autoplot()`, ggplot2 should be in `Imports`. If for some reason you would like to keep ggplot2 in `Suggests`, it is possible to register your generics only if ggplot2 is installed using `vctrs::s3_register()`. If you do this, you should copy and paste the source of `vctrs::s3_register()` into your own package to avoid adding a [vctrs](https://vctrs.r-lib.org/) dependency.
 
 ```{r, eval=FALSE}
 .onLoad <- function(...) {