diff --git a/search.json b/search.json
index 0e23193..7dad73c 100644
--- a/search.json
+++ b/search.json
@@ -263,7 +263,7 @@
"href": "dependencies.html#imports",
"title": "Dependencies",
"section": "Imports",
- "text": "Imports\nHanding imports is slightly more involved than package exports, because imported dependencies can live in two places: DESCRIPTION and the NAMESPACE.\nThe DESCRIPTION file handles package-level dependencies, specifying which packages pkgApp uses. These packages are installed whenever a user installs pkgApp.\nOn the other hand, the NAMESPACE directives manage function-level access, importing functions from other packages to be used in pkgApp and–as we’ve seen above–exporting functions from pkgApp for others to use.\nWhen pkgApp is documented (i.e., Ctrl/Cmd + Shift + D), roxygen2 tags are used to update the NAMESPACE with any imports or exports. However, the DESCRIPTION file must be edited independently:\n\n\n\nCtrl/Cmd + Shift + D updates the NAMESPACE, but it doesn’t change anything in the DESCRIPTION file.\n\n\n\n\n(a) roxygen2 does not connect the NAMESPACE to the DESCRIPTION\n\nFigure 5: roxygen2 & NAMESPACE = function-level access vs. DESCRIPTION = package-level dependencies\n\nThe differences between the dependencies listed in the NAMESPACE directives and the Imports field in the DESCRIPTION file can be a common point of confusion, which is understandable if you’ve consulted the official R documentation (specifically the Package Dependencies and Package namespaces topics).\nI’ve attempted to distill and consolidate the advice I’ve found when I’ve gone looking for (and had trouble finding) answers to the following questions:\n\nHow and where should I be importing add-on functions and packages?\nWhy and when should I import add-on packages/functions? and\nWhat happens when a package or function is imported?\n\nI’ve also added emphasis to the parts I’ve found are worth committing to memory.\nHow and where?\nThere are three ways to import add-on packages and functions into your app-package:\n\nUse a ‘fully qualified variable reference’ (i.e., the package::function() syntax) (we’re already using this method with movies_app() and scatter_plot()).\nList the package in the Import field of the DESCRIPTION file\nInclude an @import or @importFrom tag from roxygen2 (this will add import() or importFrom() in the NAMESPACE)\n\nBelow is a collection of relevant information for each method above you’re likely to come across when searching for advice on this topic:\n\n\n\n\n\n\nHow and where to import add-on package functions?\n\n\n\n\n\n\n\npackage::function()\nImport (DESCRIPTION)\n@import/@importFrom (NAMESPACE)\n\n\n\nThe official R documentation refers to the package::function() syntax as a ‘fully-qualified reference’:\n\n“A fully-qualified reference to the function f in package foo is of the form foo::f.” - Specifying imports and exports\n\nR Packages, 2ed recommends using ‘package::function()’ for all calls to add-on package functions:\n\n“Our recommended default is to call external functions using the package::function() syntax” - R Packages 2ed, In code below R/\n\nUsing ‘package::function()’ can seem tedious at first, but fortunately we have tools like tab-completion (if you’re using the Posit Workbench IDE) and packages like sinew (which we’ll cover in a later chapter)\n\n\nThe official R documentation assumes you’ll be editing the DESCRIPTION manually, but R Packages, 2ed recommends using the usethis::use_package() function to include add-on packages to the Imports field of the DESCRIRPTION file:\n\n“Remember usethis::use_package() is helpful for adding dependencies to DESCRIPTION” - Dependencies: In Practice\n\n\n\nThe official R documentation assumes you’ll be editing the NAMESPACE manually (i.e., with import() and importFrom() directives), but R Packages, 2ed assumes you’ll be building your app-package iteratively, so the authors recommend using the usethis::use_import_from():\n\n“A handy function for your interactive workflow is usethis::use_import_from()” - In code below R/\n\n\n\n\n\n\n\n\nHow and where in pkgApp\n\nWe’re already using package::function() in the two exported functions from pkgApp (movies_app() and scatter_plot()), so let’s cover when and why to list these packages and functions as imports.\n\nshow/hide explicit namespacing in movies_app()movies_app <- function() {\n shiny::shinyApp(ui = movies_ui, server = movies_server)\n}\n\n\n\nshow/hide explicit namespacing in scatter_plot()scatter_plot <- function(df, x_var, y_var, col_var, alpha_var, size_var) {\n ggplot2::ggplot(data = df,\n ggplot2::aes(x = .data[[x_var]],\n y = .data[[y_var]],\n color = .data[[col_var]])) +\n ggplot2::geom_point(alpha = alpha_var, size = size_var)\n\n}\n\n\nWhen and why?\nKnowing when and why to use each method above is just as important as knowing how and where to import add-on packages and functions, and I’ve tried to distill this decision into actionable steps below:\n\n\n\n\n\n\nWhen and why to import add-on package functions?\n\n\n\n\n\n\n\npackage::function()\nImport (DESCRIPTION)\n@import/@importFrom (NAMESPACE)\n\n\n\nIf we’re only using a handful of functions from an add-on package, using the package::function() is fine:\n\n“If a package only needs a few objects from another package it can use a fully qualified variable reference (foo::f) in the code instead of a formal import.” - Specifying imports and exports\n\nThis is the case in pkgApp for the two exported functions (i.e., ggplot2, rlang), but we should also use the package::function() syntax if there is a potential name conflict:\n\nUsing the foo::f form will be necessary when a package needs to use a function of the same name from more than one namespace.” - Specifying imports and exports\n\nR Packages, 2ed recommends defaulting to package::function() for calls to any add-on packages in the R/ folder because it makes these calls more explicit:\n\n“…the package::function() calling style is also our default recommendation for how to use your dependencies in the code below R/, because it eliminates all ambiguity.” - R packages\n\n\n\nThe official R documentation indicates any add-on package functions using package::function() should be listed in the DESCRIPTION (specifically, the Imports field).\n\n“The Imports field lists packages whose namespaces are imported from (as specified in the NAMESPACE file) but which do not need to be attached. Namespaces accessed by the :: and ::: operators must be listed here.” - Package Dependencies\n\nYou might be wondering, “What if I list a package in DESCRIPTION/Imports field, but don’t list it in the NAMESPACE?” R Packages, 2ed addresses this:\n\n“It is common for a package to be listed in Imports in DESCRIPTION, but not in NAMESPACE. The converse is not true. Every package mentioned in NAMESPACE must also be present in the Imports or Depends fields.” - Confusion about Imports\n\nOn when to use Import vs. Depends:\n\nUnless there is a good reason otherwise, you should always list packages in Imports not Depends.” - Whether to Import or Depend\n\n\n\nThe official R documentation states ‘variables exported from other packages’ need to be imported:\n\n“Variables exported from other packages with namespaces need to be imported explicitly using the directives import and importFrom” Specifying imports and exports\n\nBut it also recommends using @importFrom over @import in most cases:\n\n“Using importFrom selectively rather than import is good practice and recommended notably when importing from packages with more than a dozen exports and especially from those written by others (so what they export can change in future).” - Specifying imports and exports.\n\n‘Formal imports’ are also referred to more efficient than using package::function() in the following section (a ‘formal import’ means the add-on package function uses import() or importFrom() in the NAMESPACE):\n\n“[foo::f] is slightly less efficient than a formal import and also loses the advantage of recording all dependencies in the NAMESPACE file” - Specifying imports and exports.\n\nR Packages, 2ed, recommends minimizing the use of both (aaapkg represents a hypothetical package listed in the Imports field of the DESCRIPTION file)\n\n“Specifically, we recommend that you default to not importing anything from aaapkg into your namespace. This makes it very easy to identify which functions live outside of your package, which is especially useful when you read your code in the future. This also eliminates any concerns about name conflicts between aaapkg and your package.” Package is listed in Imports\n\nHowever, R Packages, 2ed also notes the following exceptions to this rule:\n\n“Sometimes you make such heavy use of so many functions from another package that you want to import its entire namespace.”\n“You can’t call an operator from another package via ::, so you must import it.” - Package is listed in Imports\n\nIf you happen to read the advice from the footnote, you’ll also find somewhat conflicting advice:\n\n“Always use a NAMESPACE to specify imports so that your package code isn’t harmed by other peoples’ use of Depends.” - Whether to Import or Depend: footnote reference\n\n\n\n\n\n\n\n\nWhen and why in pkgApp\n\nI think the best guidance on when and why to use package::function(), @importFrom, and the Import field in the DESCRIPTION comes from the roxygen2 documentation:\n\n“if you are using just a few functions from another package, we recommending adding the package to the Imports: field of the DESCRIPTION file and calling the functions explicitly using ::, e.g., pkg::fun()”\n“If the repetition of the package name becomes annoying you can @importFrom and drop the [package::function()]” - Importing functions\n\nFollowing this advice and the exceptions to the rule regarding ‘heavy use’ and ‘operators’ from add-on packages, we can replace the explicit namespacing from all calls to shiny functions (i.e., shiny::) with the @import tag in R/movies_app.R:\n\nshow/hide @import in movies_app()#' Movies app standalone function\n#'\n#' Wrapper function for `shinyApp()`\n#'\n#' @return shiny app\n#' \n#' \n#' @seealso [mod_var_input_ui()], [mod_var_input_server()], [mod_scatter_display_ui()], [mod_scatter_display_server()]\n#' \n#' @import shiny\n#'\n#' @export\n#' \nmovies_app <- function() {\n shinyApp(ui = movies_ui, server = movies_server)\n}\n\n\nAnd we should include @importFrom for the use of .data in R/scatter_plot.R:\n\nshow/hide @importFrom in scatter_plot()#' Create scatter plot \n#'\n#' Custom [`ggplot2`](https://ggplot2.tidyverse.org/) function for building scatter plots in `pkgApp()`.\n#' \n#' \n#' @param df `data.frame` or `tibble`\n#' @param x_var string variable mapped to `x` axis\n#' @param y_var string variable mapped to `y` axis\n#' @param col_var string variable mapped to `color`\n#' @param alpha_var number for point `alpha`\n#' @param size_var number for point `size` \n#' \n#' @return A `ggplot2` plot object\n#' \n#' \n#' @examples\n#' scatter_plot(mtcars, \n#' x_var = \"mpg\", \n#' y_var = \"disp\", \n#' col_var = \"cyl\", \n#' alpha_var = 0.5, \n#' size_var = 3)\n#' \n#' @seealso [mod_scatter_display_server()]\n#' \n#' @importFrom rlang .data\n#' \n#' @export\n#' \nscatter_plot <- function(df, x_var, y_var, col_var, alpha_var, size_var) {\n ggplot2::ggplot(data = df,\n ggplot2::aes(x = .data[[x_var]],\n y = .data[[y_var]],\n color = .data[[col_var]])) +\n ggplot2::geom_point(alpha = alpha_var, size = size_var)\n\n}\n\n\nFinally, we need to add each add-on package to the Imports field in the DESCRIPTION using usethis::use_package():\n\nusethis::use_package(\"shiny\")\nusethis::use_package(\"shinythemes\")\nusethis::use_package(\"stringr\")\nusethis::use_package(\"ggplot2\")\nusethis::use_package(\"rlang\")\n\n\nshow/hide output from usethis::use_package()✔ Setting active project to '/Users/mjfrigaard/projects/pkgs/apps/pkgApp'\n✔ Adding 'shiny' to Imports field in DESCRIPTION\n• Refer to functions with `shiny::fun()`\n✔ Adding 'shinythemes' to Imports field in DESCRIPTION\n• Refer to functions with `shinythemes::fun()`\n✔ Adding 'stringr' to Imports field in DESCRIPTION\n• Refer to functions with `stringr::fun()`\n✔ Adding 'ggplot2' to Imports field in DESCRIPTION\n• Refer to functions with `ggplot2::fun()`\n✔ Adding 'rlang' to Imports field in DESCRIPTION\n• Refer to functions with `rlang::fun()`\n\n\nWhen I load, document, and install pkgApp, the changes are made to the NAMESPACE:\n\nCtrl/Cmd + Shift + L / D / B\n\nBelow are the updated NAMESPACE and DESCRIPTION files:\n\n\n\n\n\n(a) Updated NAMESPACE with import and `importFrom\n\n\n\n\n\n(b) Updated DESCRIPTION with all Imports\n\n\n\nFigure 6: roxygen2 will update the NAMESPACE, but usethis::use_package() is needed to update the DESCRIPTION\n\n\nWhen we run movies_app(), we see the application launches and we can still run the scatter_plot() examples:\n\n\n\n\n\n(a) movies_app() works\n\n\n\n\n\n(b) Examples in ?scatter_plot\n\n\n\nFigure 7: Confirming we still have full functionality in pkgApp\n\n\nIn the next section, we’re going to cover what happens when these packages and functions were included as imports in pkgApp.\nWhat happens?\nThis section gets a bit technical, but I’ve done my best to include what I consider to be the necessary distinctions between using explicit namespacing (package::function()), @importFrom, @import, and the Imports field in the DESCRIPTION.\n\n\n\n\n\n\nWhat happens to imported add-on package functions?\n\n\n\n\n\npackage::function()\nImport (DESCRIPTION)\n@import/@importFrom (NAMESPACE)\n\n\n\n\n“Evaluating foo::f will cause package foo to be loaded, but not attached, if it was not loaded already” - Specifying imports and exports.\n\nThis means if users of our package want to use foo::f, they will have to use foo::f.\n\n\nR Packages, 2ed describes what happens to packages listed in Imports:\n\nConsider a dependency that is listed in DESCRIPTION in Imports:\nImports:\n aaapkg\nThe code inside your package can assume that aaapkg is installed whenever pkg is installed.\n\nR Packages, 2ed also recommends using Imports (instead of Depends) and describes the the differences in their actions (i.e., loading vs. loaded & attaching)\n\n“The main difference is that a package you list in Imports will just be loaded when you use it, whereas a package you list in Depends will be attached when your package is attached. - Whether to Import or Depend\n\n\n\nImports are covered in Advanced R, 2ed:\n\n“Each namespace has an imports environment that can contain bindings to functions used by the package that are defined in another package. The imports environment is controlled by the package developer with the NAMESPACE file. Specifically, directives such as importFrom() and imports() populate this environment.” - Function lookup inside a package\n\n\n\n\n\n\n\nWhat happened in pkgApp\n\nFirst we should confirm we’re still only exporting movies_app() and scatter_plot() from pkgApp:\n\nls(name = \"package:pkgApp\")\n\n[1] \"movies_app\" \"scatter_plot\"\nThere are now five packages listed in the Imports field in the DESCRIPTION file–are these packages on the search list?\n\npkgs <- c(\"package:shiny\", \"package:rlang\", \n \"package:ggplot2\", \"package:shinythemes\", \n \"package:stringr\")\npkgs %in% search()\n\n[1] TRUE FALSE FALSE FALSE FALSE\nThis demonstrates that only shiny is attached with pkgApp (because we included it with @import/import() in the NAMESPACE). However, all five packages are included in the loadedNamespaces() with pkgApp.\n\npkgs <- c(\"shiny\", \"rlang\", \"ggplot2\", \n \"shinythemes\", \"stringr\")\npkgs %in% loadedNamespaces()\n\n[1] TRUE TRUE TRUE TRUE TRUE\nSo we can still access these functions using the package::function() syntax:\n\n\n\nggplot2::ggplot(data = mtcars, \n ggplot2::aes(x = disp, y = mpg)) + \n ggplot2::geom_point()\n\n\n\n\nggplot2 functions are still available if we explicitly namespace\n\n\n\n\n\n\n\n\nNew Git Branch\n\nThe code for this section is in the [04_pkg-imports] branch of the [pkgApp] repo."
+ "text": "Imports\nHanding imports is slightly more involved than package exports, because imported dependencies can live in two places: DESCRIPTION and the NAMESPACE.\nThe DESCRIPTION file handles package-level dependencies, specifying which packages pkgApp uses. These packages are installed whenever a user installs pkgApp.\nOn the other hand, the NAMESPACE directives manage function-level access, importing functions from other packages to be used in pkgApp and–as we’ve seen above–exporting functions from pkgApp for others to use.\nWhen pkgApp is documented (i.e., Ctrl/Cmd + Shift + D), roxygen2 tags are used to update the NAMESPACE with any imports or exports. However, the DESCRIPTION file must be edited independently:\n\n\n\nCtrl/Cmd + Shift + D updates the NAMESPACE, but it doesn’t change anything in the DESCRIPTION file.\n\n\n\n\n(a) roxygen2 does not connect the NAMESPACE to the DESCRIPTION\n\nFigure 5: roxygen2 & NAMESPACE = function-level access vs. DESCRIPTION = package-level dependencies\n\nThe differences between the dependencies listed in the NAMESPACE directives and the Imports field in the DESCRIPTION file can be a common point of confusion, which is understandable if you’ve consulted the official R documentation (specifically the Package Dependencies and Package namespaces topics).\nI’ve attempted to distill and consolidate the advice I’ve found when I’ve gone looking for (and had trouble finding) answers to the following questions:\n\nHow and where should I be importing add-on functions and packages?\nWhy and when should I import add-on packages/functions? and\nWhat happens when a package or function is imported?\n\nI’ve also added emphasis to the parts I’ve found are worth committing to memory.\nHow and where?\nThere are three ways to import add-on packages and functions into your app-package:\n\nUse a ‘fully qualified variable reference’ (i.e., the package::function() syntax) (we’re already using this method with movies_app() and scatter_plot()).\nList the package in the Import field of the DESCRIPTION file\nInclude an @import or @importFrom tag from roxygen2 (this will add import() or importFrom() in the NAMESPACE)\n\nBelow is a collection of relevant information for each method above you’re likely to come across when searching for advice on this topic:\n\n\n\n\n\n\nHow and where to import add-on package functions?\n\n\n\n\n\n\n\npackage::function()\nImports (DESCRIPTION)\n@import/@importFrom (NAMESPACE)\n\n\n\nThe official R documentation refers to the package::function() syntax as a ‘fully-qualified reference’:\n\n“A fully-qualified reference to the function f in package foo is of the form foo::f.” - Specifying imports and exports\n\nR Packages, 2ed recommends using ‘package::function()’ for all calls to add-on package functions:\n\n“Our recommended default is to call external functions using the package::function() syntax” - R Packages 2ed, In code below R/\n\nUsing ‘package::function()’ can seem tedious at first, but fortunately we have tools like tab-completion (if you’re using the Posit Workbench IDE) and packages like sinew (which we’ll cover in a later chapter)\n\n\nThe official R documentation assumes you’ll be editing the DESCRIPTION manually, but R Packages, 2ed recommends using the usethis::use_package() function to include add-on packages to the Imports field of the DESCRIRPTION file:\n\n“Remember usethis::use_package() is helpful for adding dependencies to DESCRIPTION” - Dependencies: In Practice\n\n\n\nThe official R documentation assumes you’ll be editing the NAMESPACE manually (i.e., with import() and importFrom() directives), but R Packages, 2ed assumes you’ll be building your app-package iteratively, so the authors recommend using the usethis::use_import_from():\n\n“A handy function for your interactive workflow is usethis::use_import_from()” - In code below R/\n\n\n\n\n\n\n\n\nHow and where in pkgApp\n\nWe’re already using package::function() in the two exported functions from pkgApp (movies_app() and scatter_plot()), so let’s cover when and why to list these packages and functions as imports.\n\nshow/hide explicit namespacing in movies_app()movies_app <- function() {\n shiny::shinyApp(ui = movies_ui, server = movies_server)\n}\n\n\n\nshow/hide explicit namespacing in scatter_plot()scatter_plot <- function(df, x_var, y_var, col_var, alpha_var, size_var) {\n ggplot2::ggplot(data = df,\n ggplot2::aes(x = .data[[x_var]],\n y = .data[[y_var]],\n color = .data[[col_var]])) +\n ggplot2::geom_point(alpha = alpha_var, size = size_var)\n\n}\n\n\nWhen and why?\nKnowing when and why to use each method above is just as important as knowing how and where to import add-on packages and functions, and I’ve tried to distill this decision into actionable steps below:\n\n\n\n\n\n\nWhen and why to import add-on package functions?\n\n\n\n\n\n\n\npackage::function()\nImports (DESCRIPTION)\n@import/@importFrom (NAMESPACE)\n\n\n\nIf we’re only using a handful of functions from an add-on package, using the package::function() is fine:\n\n“If a package only needs a few objects from another package it can use a fully qualified variable reference (foo::f) in the code instead of a formal import.” - Specifying imports and exports\n\nThis is the case in pkgApp for the two exported functions (i.e., ggplot2, rlang), but we should also use the package::function() syntax if there is a potential name conflict:\n\nUsing the foo::f form will be necessary when a package needs to use a function of the same name from more than one namespace.” - Specifying imports and exports\n\nR Packages, 2ed recommends defaulting to package::function() for calls to any add-on packages in the R/ folder because it makes these calls more explicit:\n\n“…the package::function() calling style is also our default recommendation for how to use your dependencies in the code below R/, because it eliminates all ambiguity.” - R packages\n\n\n\nThe official R documentation indicates any add-on package functions using package::function() should be listed in the DESCRIPTION (specifically, the Imports field).\n\n“The Imports field lists packages whose namespaces are imported from (as specified in the NAMESPACE file) but which do not need to be attached. Namespaces accessed by the :: and ::: operators must be listed here.” - Package Dependencies\n\nYou might be wondering, “What if I list a package in DESCRIPTION/Imports field, but don’t list it in the NAMESPACE?” R Packages, 2ed addresses this:\n\n“It is common for a package to be listed in Imports in DESCRIPTION, but not in NAMESPACE. The converse is not true. Every package mentioned in NAMESPACE must also be present in the Imports or Depends fields.” - Confusion about Imports\n\nOn when to use Import vs. Depends:\n\nUnless there is a good reason otherwise, you should always list packages in Imports not Depends.” - Whether to Import or Depend\n\n\n\nThe official R documentation states ‘variables exported from other packages’ need to be imported:\n\n“Variables exported from other packages with namespaces need to be imported explicitly using the directives import and importFrom” Specifying imports and exports\n\nBut it also recommends using @importFrom over @import in most cases:\n\n“Using importFrom selectively rather than import is good practice and recommended notably when importing from packages with more than a dozen exports and especially from those written by others (so what they export can change in future).” - Specifying imports and exports.\n\n‘Formal imports’ are also referred to more efficient than using package::function() in the following section (a ‘formal import’ means the add-on package function uses import() or importFrom() in the NAMESPACE):\n\n“[foo::f] is slightly less efficient than a formal import and also loses the advantage of recording all dependencies in the NAMESPACE file” - Specifying imports and exports.\n\nR Packages, 2ed, recommends minimizing the use of both (aaapkg represents a hypothetical package listed in the Imports field of the DESCRIPTION file)\n\n“Specifically, we recommend that you default to not importing anything from aaapkg into your namespace. This makes it very easy to identify which functions live outside of your package, which is especially useful when you read your code in the future. This also eliminates any concerns about name conflicts between aaapkg and your package.” Package is listed in Imports\n\nHowever, R Packages, 2ed also notes the following exceptions to this rule:\n\n“Sometimes you make such heavy use of so many functions from another package that you want to import its entire namespace.”\n“You can’t call an operator from another package via ::, so you must import it.” - Package is listed in Imports\n\nIf you happen to read the advice from the footnote, you’ll also find somewhat conflicting advice:\n\n“Always use a NAMESPACE to specify imports so that your package code isn’t harmed by other peoples’ use of Depends.” - Whether to Import or Depend: footnote reference\n\n\n\n\n\n\n\n\nWhen and why in pkgApp\n\nI think the best guidance on when and why to use package::function(), @importFrom, and the Import field in the DESCRIPTION comes from the roxygen2 documentation:\n\n“if you are using just a few functions from another package, we recommending adding the package to the Imports: field of the DESCRIPTION file and calling the functions explicitly using ::, e.g., pkg::fun()”\n“If the repetition of the package name becomes annoying you can @importFrom and drop the [package::function()]” - Importing functions\n\nFollowing this advice and the exceptions to the rule regarding ‘heavy use’ and ‘operators’ from add-on packages, we can replace the explicit namespacing from all calls to shiny functions (i.e., shiny::) with the @import tag in R/movies_app.R:\n\nshow/hide @import in movies_app()#' Movies app standalone function\n#'\n#' Wrapper function for `shinyApp()`\n#'\n#' @return shiny app\n#' \n#' \n#' @seealso [mod_var_input_ui()], [mod_var_input_server()], [mod_scatter_display_ui()], [mod_scatter_display_server()]\n#' \n#' @import shiny\n#'\n#' @export\n#' \nmovies_app <- function() {\n shinyApp(ui = movies_ui, server = movies_server)\n}\n\n\nAnd we should include @importFrom for the use of .data in R/scatter_plot.R:\n\nshow/hide @importFrom in scatter_plot()#' Create scatter plot \n#'\n#' Custom [`ggplot2`](https://ggplot2.tidyverse.org/) function for building scatter plots in `pkgApp()`.\n#' \n#' \n#' @param df `data.frame` or `tibble`\n#' @param x_var string variable mapped to `x` axis\n#' @param y_var string variable mapped to `y` axis\n#' @param col_var string variable mapped to `color`\n#' @param alpha_var number for point `alpha`\n#' @param size_var number for point `size` \n#' \n#' @return A `ggplot2` plot object\n#' \n#' \n#' @examples\n#' scatter_plot(mtcars, \n#' x_var = \"mpg\", \n#' y_var = \"disp\", \n#' col_var = \"cyl\", \n#' alpha_var = 0.5, \n#' size_var = 3)\n#' \n#' @seealso [mod_scatter_display_server()]\n#' \n#' @importFrom rlang .data\n#' \n#' @export\n#' \nscatter_plot <- function(df, x_var, y_var, col_var, alpha_var, size_var) {\n ggplot2::ggplot(data = df,\n ggplot2::aes(x = .data[[x_var]],\n y = .data[[y_var]],\n color = .data[[col_var]])) +\n ggplot2::geom_point(alpha = alpha_var, size = size_var)\n\n}\n\n\nFinally, we need to add each add-on package to the Imports field in the DESCRIPTION using usethis::use_package():\n\nusethis::use_package(\"shiny\")\nusethis::use_package(\"shinythemes\")\nusethis::use_package(\"stringr\")\nusethis::use_package(\"ggplot2\")\nusethis::use_package(\"rlang\")\n\n\nshow/hide output from usethis::use_package()✔ Setting active project to '/Users/mjfrigaard/projects/pkgs/apps/pkgApp'\n✔ Adding 'shiny' to Imports field in DESCRIPTION\n• Refer to functions with `shiny::fun()`\n✔ Adding 'shinythemes' to Imports field in DESCRIPTION\n• Refer to functions with `shinythemes::fun()`\n✔ Adding 'stringr' to Imports field in DESCRIPTION\n• Refer to functions with `stringr::fun()`\n✔ Adding 'ggplot2' to Imports field in DESCRIPTION\n• Refer to functions with `ggplot2::fun()`\n✔ Adding 'rlang' to Imports field in DESCRIPTION\n• Refer to functions with `rlang::fun()`\n\n\nWhen I load, document, and install pkgApp, the changes are made to the NAMESPACE:\n\nCtrl/Cmd + Shift + L / D / B\n\nBelow are the updated NAMESPACE and DESCRIPTION files:\n\n\n\n\n\n(a) Updated NAMESPACE with import and `importFrom\n\n\n\n\n\n(b) Updated DESCRIPTION with all Imports\n\n\n\nFigure 6: roxygen2 will update the NAMESPACE, but usethis::use_package() is needed to update the DESCRIPTION\n\n\nWhen we run movies_app(), we see the application launches and we can still run the scatter_plot() examples:\n\n\n\n\n\n(a) movies_app() works\n\n\n\n\n\n(b) Examples in ?scatter_plot\n\n\n\nFigure 7: Confirming we still have full functionality in pkgApp\n\n\nIn the next section, we’re going to cover what happens when these packages and functions were included as imports in pkgApp.\nWhat happens?\nThis section gets a bit technical, but I’ve done my best to include what I consider to be the necessary distinctions between using explicit namespacing (package::function()), @importFrom, @import, and the Imports field in the DESCRIPTION.\n\n\n\n\n\n\nWhat happens to imported add-on package functions?\n\n\n\n\n\npackage::function()\nImports (DESCRIPTION)\n@import/@importFrom (NAMESPACE)\n\n\n\n\n“Evaluating foo::f will cause package foo to be loaded, but not attached, if it was not loaded already” - Specifying imports and exports.\n\nThis means if users of our package want to use foo::f, they will have to use foo::f.\n\n\nR Packages, 2ed describes what happens to packages listed in Imports:\n\nConsider a dependency that is listed in DESCRIPTION in Imports:\nImports:\n aaapkg\nThe code inside your package can assume that aaapkg is installed whenever pkg is installed.\n\nR Packages, 2ed also recommends using Imports (instead of Depends) and describes the the differences in their actions (i.e., loading vs. loaded & attaching)\n\n“The main difference is that a package you list in Imports will just be loaded when you use it, whereas a package you list in Depends will be attached when your package is attached. - Whether to Import or Depend\n\n\n\nImports are covered in Advanced R, 2ed:\n\n“Each namespace has an imports environment that can contain bindings to functions used by the package that are defined in another package. The imports environment is controlled by the package developer with the NAMESPACE file. Specifically, directives such as importFrom() and imports() populate this environment.” - Function lookup inside a package\n\n\n\n\n\n\n\nWhat happened in pkgApp\n\nFirst we should confirm we’re still only exporting movies_app() and scatter_plot() from pkgApp:\n\nls(name = \"package:pkgApp\")\n\n[1] \"movies_app\" \"scatter_plot\"\nThere are now five packages listed in the Imports field in the DESCRIPTION file–are these packages on the search list?\n\npkgs <- c(\"package:shiny\", \"package:rlang\", \n \"package:ggplot2\", \"package:shinythemes\", \n \"package:stringr\")\npkgs %in% search()\n\n[1] TRUE FALSE FALSE FALSE FALSE\nThis demonstrates that only shiny is attached with pkgApp (because we included it with @import/import() in the NAMESPACE). However, all five packages are included in the loadedNamespaces() with pkgApp.\n\npkgs <- c(\"shiny\", \"rlang\", \"ggplot2\", \n \"shinythemes\", \"stringr\")\npkgs %in% loadedNamespaces()\n\n[1] TRUE TRUE TRUE TRUE TRUE\nSo we can still access these functions using the package::function() syntax:\n\n\n\nggplot2::ggplot(data = mtcars, \n ggplot2::aes(x = disp, y = mpg)) + \n ggplot2::geom_point()\n\n\n\n\nggplot2 functions are still available if we explicitly namespace\n\n\n\n\n\n\n\n\nNew Git Branch\n\nThe code for this section is in the [04_pkg-imports] branch of the [pkgApp] repo."
},
{
"objectID": "dependencies.html#checking-dependencies",
diff --git a/sitemap.xml b/sitemap.xml
index 1a9448a..fe41b18 100644
--- a/sitemap.xml
+++ b/sitemap.xml
@@ -2,98 +2,98 @@
https://mjfrigaard.github.io/shinyap/index.html
- 2023-08-28T18:44:19.032Z
+ 2023-08-28T19:18:29.594Z
https://mjfrigaard.github.io/shinyap/intro.html
- 2023-08-28T18:44:19.041Z
+ 2023-08-28T19:18:29.605Z
https://mjfrigaard.github.io/shinyap/shiny.html
- 2023-08-28T18:44:19.125Z
+ 2023-08-28T19:18:29.694Z
https://mjfrigaard.github.io/shinyap/packages.html
- 2023-08-28T18:44:19.174Z
+ 2023-08-28T19:18:29.743Z
https://mjfrigaard.github.io/shinyap/devtools.html
- 2023-08-28T18:44:19.209Z
+ 2023-08-28T19:18:29.795Z
https://mjfrigaard.github.io/shinyap/app_packages.html
- 2023-08-28T18:44:19.222Z
+ 2023-08-28T19:18:29.809Z
https://mjfrigaard.github.io/shinyap/roxygen2.html
- 2023-08-28T18:44:19.273Z
+ 2023-08-28T19:18:29.857Z
https://mjfrigaard.github.io/shinyap/dependencies.html
- 2023-08-28T18:44:19.340Z
+ 2023-08-28T19:18:29.931Z
https://mjfrigaard.github.io/shinyap/app.html
- 2023-08-28T18:44:19.387Z
+ 2023-08-28T19:18:29.959Z
https://mjfrigaard.github.io/shinyap/data.html
- 2023-08-28T18:44:19.426Z
+ 2023-08-28T19:18:29.997Z
https://mjfrigaard.github.io/shinyap/inst_www.html
- 2023-08-28T18:44:19.455Z
+ 2023-08-28T19:18:30.028Z
https://mjfrigaard.github.io/shinyap/tests.html
- 2023-08-28T18:44:19.472Z
+ 2023-08-28T19:18:30.043Z
https://mjfrigaard.github.io/shinyap/frameworks.html
- 2023-08-28T18:44:19.480Z
+ 2023-08-28T19:18:30.050Z
https://mjfrigaard.github.io/shinyap/golem.html
- 2023-08-28T18:44:19.492Z
+ 2023-08-28T19:18:30.061Z
https://mjfrigaard.github.io/shinyap/leprechaun.html
- 2023-08-28T18:44:19.499Z
+ 2023-08-28T19:18:30.069Z
https://mjfrigaard.github.io/shinyap/rhino.html
- 2023-08-28T18:44:19.507Z
+ 2023-08-28T19:18:30.076Z
https://mjfrigaard.github.io/shinyap/special_topics.html
- 2023-08-28T18:44:19.514Z
+ 2023-08-28T19:18:30.083Z
https://mjfrigaard.github.io/shinyap/debugging.html
- 2023-08-28T18:44:19.521Z
+ 2023-08-28T19:18:30.090Z
https://mjfrigaard.github.io/shinyap/css.html
- 2023-08-28T18:44:19.528Z
+ 2023-08-28T19:18:30.097Z
https://mjfrigaard.github.io/shinyap/js.html
- 2023-08-28T18:44:19.535Z
+ 2023-08-28T19:18:30.104Z
https://mjfrigaard.github.io/shinyap/code_tools.html
- 2023-08-28T18:44:19.546Z
+ 2023-08-28T19:18:30.115Z
https://mjfrigaard.github.io/shinyap/glossary.html
- 2023-08-28T18:44:19.554Z
+ 2023-08-28T19:18:30.123Z
https://mjfrigaard.github.io/shinyap/github.html
- 2023-08-28T18:44:19.568Z
+ 2023-08-28T19:18:30.136Z
https://mjfrigaard.github.io/shinyap/create.html
- 2023-08-28T18:44:19.580Z
+ 2023-08-28T19:18:30.149Z