Sure, sorry I was not clear. What I meant by input parameters is more around typical R function parameters, not the specific inputs available in a shiny app. I typically have a lot of reactives within each of the modules, and they constructed much like this:
# important reactive to create processed result
reactive({
# a bunch of R code lines that do something important
return(some_object)
})
The only parameter I define explicitly in reactive is of course the expression of R code. Contrast that with the typical module UI and server functions such as coolModuleUI <- function(id, param1, param2, <etc>) { # ui code } and coolModule <- function(input, output, session, param1, param2, <etc>) { # server-side code } that have obvious parameters and hence can be documented in a similar way as say any R function in a package with Roxygen or other means. So I'm just struggling with how to ensure that the rest of the developers on my complex apps can fully grasp the intent and purpose of all of these reactives inside the modules, and finding an effective way of documenting those in addition to documenting the module functions themselves. Hope that makes more sense!