Move callModule() to separate .Rd; add various links to docs (#2889)

* Move callModule() to separate .Rd; add various links to docs

* Remove callModule param from moduleServer docs

* document

* Update R/modules.R

* Rebuild docs

* Add callModule to pkgdown

Co-authored-by: Winston Chang <winston@stdout.org>

R/modules.R

@@ -44,14 +44,13 @@ createSessionProxy <- function(parentSession, ...) {
 #' <http://shiny.rstudio.com/articles/modules.html> to learn more.
 #'
 #' Starting in Shiny 1.5.0, we recommend using `moduleServer` instead of
-#' `callModule`, because the syntax is a little easier to understand, and
-#' modules created with `moduleServer` can be tested with [`testServer()`].
+#' [`callModule()`], because the syntax is a little easier
+#' to understand, and modules created with `moduleServer` can be tested with
+#' [`testServer()`].
 #'
 #' @param module A Shiny module server function.
 #' @param id An ID string that corresponds with the ID used to call the module's
 #'   UI function.
-#' @param ... For `callModule`, additional parameters to pass to module server
-#'   function.
 #' @param session Session from which to make a child scope (the default should
 #'   almost always be used).
 #'
@@ -143,7 +142,21 @@ moduleServer <- function(id, module, session = getDefaultReactiveDomain()) {
 }
 
 
-#' @rdname moduleServer
+#' Invoke a Shiny module
+#'
+#' Note: As of Shiny 1.5.0, we recommend using [`moduleServer()`] instead of
+#' [`callModule()`], because the syntax is a little easier
+#' to understand, and modules created with `moduleServer` can be tested with
+#' [`testServer()`].
+#'
+#' @param module A Shiny module server function
+#' @param id An ID string that corresponds with the ID used to call the module's
+#'   UI function
+#' @param ... Additional parameters to pass to module server function
+#' @param session Session from which to make a child scope (the default should
+#'   almost always be used)
+#'
+#' @return The return value, if any, from executing the module server function
 #' @export
 callModule <- function(module, id, ..., session = getDefaultReactiveDomain()) {
   if (!inherits(session, c("ShinySession", "session_proxy", "MockShinySession"))) {

R/test-server.R

@@ -10,7 +10,7 @@ isModuleServer <- function(x) {
 #' modules.
 #' @param app The path to an application or module to test. In addition to
 #'   paths, applications may be represented by any object suitable for coercion
-#'   to an `appObj` by `as.shiny.appobj`. Application server functions must
+#'   to an `appObj` by [`as.shiny.appobj`]. Application server functions must
 #'   include a `session` argument in order to be tested. If `app` is `NULL` or
 #'   not supplied, the nearest enclosing directory that is a Shiny app, starting
 #'   with the current directory, is used.
@@ -21,9 +21,10 @@ isModuleServer <- function(x) {
 #' @param args Additional arguments to pass to the module function. If `app` is
 #'   a module, and no `id` argument is provided, one will be generated and
 #'   supplied automatically.
-#' @param session The `MockShinySession` object to use as the reactive domain.
-#'   The same session object is used as the domain both during invocation of the
-#'   server or module under test and during evaluation of `expr`.
+#' @param session The [`MockShinySession`] object to use as the [reactive
+#'   domain][shiny::domains]. The same session object is used as the domain both
+#'   during invocation of the server or module under test and during evaluation
+#'   of `expr`.
 #' @include mock-session.R
 #' @rdname testServer
 #' @examples

man/callModule.Rd

@@ -0,0 +1,28 @@
+% Generated by roxygen2: do not edit by hand
+% Please edit documentation in R/modules.R
+\name{callModule}
+\alias{callModule}
+\title{Invoke a Shiny module}
+\usage{
+callModule(module, id, ..., session = getDefaultReactiveDomain())
+}
+\arguments{
+\item{module}{A Shiny module server function}
+
+\item{id}{An ID string that corresponds with the ID used to call the module's
+UI function}
+
+\item{...}{Additional parameters to pass to module server function}
+
+\item{session}{Session from which to make a child scope (the default should
+almost always be used)}
+}
+\value{
+The return value, if any, from executing the module server function
+}
+\description{
+Note: As of Shiny 1.5.0, we recommend using \code{\link[=moduleServer]{moduleServer()}} instead of
+\code{\link[=callModule]{callModule()}}, because the syntax is a little easier
+to understand, and modules created with \code{moduleServer} can be tested with
+\code{\link[=testServer]{testServer()}}.
+}

man/moduleServer.Rd

@@ -2,12 +2,9 @@
 % Please edit documentation in R/modules.R
 \name{moduleServer}
 \alias{moduleServer}
-\alias{callModule}
 \title{Shiny modules}
 \usage{
 moduleServer(id, module, session = getDefaultReactiveDomain())
-
-callModule(module, id, ..., session = getDefaultReactiveDomain())
 }
 \arguments{
 \item{id}{An ID string that corresponds with the ID used to call the module's
@@ -17,9 +14,6 @@ UI function.}
 
 \item{session}{Session from which to make a child scope (the default should
 almost always be used).}
-
-\item{...}{For \code{callModule}, additional parameters to pass to module server
-function.}
 }
 \value{
 The return value, if any, from executing the module server function
@@ -32,8 +26,9 @@ modules are easier to reuse and easier to reason about. See the article at
 }
 \details{
 Starting in Shiny 1.5.0, we recommend using \code{moduleServer} instead of
-\code{callModule}, because the syntax is a little easier to understand, and
-modules created with \code{moduleServer} can be tested with \code{\link[=testServer]{testServer()}}.
+\code{\link[=callModule]{callModule()}}, because the syntax is a little easier
+to understand, and modules created with \code{moduleServer} can be tested with
+\code{\link[=testServer]{testServer()}}.
 }
 \examples{
 # Define the UI for a module

man/testServer.Rd

@@ -9,7 +9,7 @@ testServer(app = NULL, expr, args = list(), session = MockShinySession$new())
 \arguments{
 \item{app}{The path to an application or module to test. In addition to
 paths, applications may be represented by any object suitable for coercion
-to an \code{appObj} by \code{as.shiny.appobj}. Application server functions must
+to an \code{appObj} by \code{\link{as.shiny.appobj}}. Application server functions must
 include a \code{session} argument in order to be tested. If \code{app} is \code{NULL} or
 not supplied, the nearest enclosing directory that is a Shiny app, starting
 with the current directory, is used.}
@@ -23,9 +23,9 @@ along with any other values created inside of the server function.}
 a module, and no \code{id} argument is provided, one will be generated and
 supplied automatically.}
 
-\item{session}{The \code{MockShinySession} object to use as the reactive domain.
-The same session object is used as the domain both during invocation of the
-server or module under test and during evaluation of \code{expr}.}
+\item{session}{The \code{\link{MockShinySession}} object to use as the \link[shiny:domains]{reactive domain}. The same session object is used as the domain both
+during invocation of the server or module under test and during evaluation
+of \code{expr}.}
 }
 \description{
 A way to test the reactive interactions in Shiny applications. Reactive

tools/documentation/pkgdown.yml

@@ -210,6 +210,7 @@ reference:
     contents:
       - NS
       - moduleServer
+      - callModule
   - title: Embedding
     desc: Functions that are intended for third-party packages that embed Shiny applications.
     contents: