[Discussion] New skeleton for shiny Modules

[ColinFay]

Based on the recent changes in shiny (see also #455), the recommended way to write module is now with moduleServer().

Here is the change in the way to write it:

# VERSION < 1.5.0 

name_ui <- function(id){
  ns <- NS(id)
  tagList(
    actionButton(ns("go"), "go")
  )
}

name_server <- function(input, output, session){
  observeEvent( input$go , {
    print("hey")
  })
  
}

library(shiny)
ui <- function(request){
  tagList(
    name_ui("name_ui")
  )
}

server <- function(
  input, 
  output, 
  session
){
  callModule(name_server, "name_ui")
}

shinyApp(ui, server)

which is now written:

# VERSION >= 1.5.0 

name_ui <- function(id){
  ns <- NS(id)
  tagList(
    actionButton(ns("go"), "go")
  )
}

name_server <- function(id) {
  moduleServer(
    id,
    function(input, output, session) {
      observeEvent( input$go , {
        print("hey")
      })
    }
  )
}

library(shiny)
ui <- function(request){
  tagList(
    name_ui("name_ui")
  )
}

server <- function(
  input, 
  output, 
  session
){
  name_server("name_ui")
}

shinyApp(ui, server)

I'm a little against about writing the module code this way, as it creates a complex, nested structure.

name_server <- function(id) {
  moduleServer(
    id,
    function(input, output, session) {
      observeEvent( input$go , {
        print("hey")
      })
    }
  )
}

I think we could make things clearer by using this pattern:

name_ui <- function(id){
  ns <- NS(id)
  tagList(
    actionButton(ns("go"), "go")
  )
}

name_server_core <- function(input, output, session) {
  observeEvent( input$go , {
    print("hey")
  })
}

name_server <- function(id) {
  moduleServer(
    id,
    name_server_core
  )
}

It will mean we need 3 functions, but it seems to me easier to write and understand: we still write server functions the way we use to, and it makes converting old code easier.
And we would actually only be working with two functions, the last one will not need to change regularly (expect when changing the server function arguments).

I think this should be the default skeleton.

What do y'all think about this?

[VincentGuyader]

"Woaw Colin what a brilliant idea, how lucky am I to work with a talented mind like yours.
Ps: I love you"

[jonthegeek]

This seems like the right answer to me (and is how I've been writing my shiny 1.5 experiments). I see the moduleServer version as the one you'd export, so users can just use your module without anything fancy, but then the core function is internal and does the heavy lifting.

[julianstanley]

I agree with Jon--this looks great, Colin!

Two reasons for me:

(1) The extra layer of indentation in the new 1.5 version has been a bit annoying for me, since I can't fit as much in each line. So, a name_server_core pattern fixes that.

(2) I think this also makes for an easier transition. Basically, if users still want to use the callModule pattern for whatever reason, they can--they'll just call name_server_core instead.

[KasperThystrup]

Just a quick question, with this approach, does additional arguments have to be added manually in both the core function and the inner module?

E.g.

name_server_core <- function(input, output, session, argument_A, argument_B, stop_arguing) {
  observeEvent( input$go , {
    print("hey")
  })
}

name_server <- function(id, argument_A, argument_B, stop_arguing) {
  moduleServer(
    id,
    name_server_core
  )
}

[ColinFay]

@KasperThystrup Yes, this is indeed my current issue with this format.

I think that for now we will stick with the one suggested by the {shiny} doc until I've wrapped my head around this :)

[KasperThystrup]

Using the ... argument in the name_server_core could circumvent the issue, but at the cost of transparency.

[ColinFay]

That's indeed what I suggested in rstudio/shiny#3008, but I'm not sure it's gonna be there soon unfortunately :/

[ColinFay]

I'll leave this discussion open for now.

The new add_module version add the structure for the recommended {shiny} way.

We'll see how it evolves.

[antoine-sachet]

I agree with what Joe Cheng said in the other thread over at rstudio/shiny: if you indent moduleServer like below, it's really no big deal.

name_ui <- function(id){
  ns <- NS(id)
  tagList(
    # ...
  )
}

name_server <- function(id) {
  moduleServer(id, function(input, output, session) {
    data <- reactive({
      # ...
    })
    # ...
  })
}

The server_core idea is interesting but I certainly do not want to have to edit two lines to add an argument. If the module becomes significant in size, I'll have to scroll down, I'll probably forget, etc.

I really don't mind the 1 extra indentation (but then I typically only use a double space so my indents are quite small) and the extra complexity of having to duplicate arguments is not worth it to me.

That being said, I thought I'd shoot myself in the foot and point out that there is a way to do what you want without any update from shiny. You just need your server_core closure to be in the environment within name_server, like it would be if you had defined inside.

So the following works and only requires the arguments in the name server:

name_server_core <- function(input, output, session) {
  observeEvent( input$go , {
    print("hey")
  })
}

name_server <- function(id, argument_A, argument_B, stop_arguing) {
  environment(name_server_core) <- environment()
  moduleServer(id, name_server_core)
}

I am not sure this is any better as I find it highly counter-intuitive to add arguments in the name_server instead of the name_server_core, but at least they're not duplicated. Also, I expect IDE linting to go a bit crazy ("no symbol argument_A in scope") in the body of name_server_core which will be very annoying.

[KasperThystrup]

One slightly more complex approach would be to draw inspiration from e.g. usethis::data_raw and combine with module generation, in order to set another layer of functionality:

Making a golem::new_module() function, which opens a blank R script, where you can define the ui element and server element itself, yet without navigating the mod_#ui and mod#_server functions.
Finally, with the functions being ready, one could call golem::add_mod(ui = x, server = y), for golem to automatically generate the module file inside R/.

##A denotes automatically generated lines

new_module(name = "test")   # Generates mod/test.R
< Navigates to dev/test.R >
# code to prepare "test" goes here.


# Set up the UI element here Same as in golem::add_module!!
ui <- function(id) {        ##A
  ns <- NS(id)               ##A
  taglist(
    shiny::checkboxInput(inputId = ns("like"), label = "Do you like My little pony?", value = TRUE)
  )
}

# Set up the server element here and make sure to add arguments to server function if needed.
server <- function(input, output, session) {        ##A
  bro_niesNotAllowed <- do.stuff(input$notAllowed)
  ...
}

golem::add_module(ui = ui, server = server, name = name)     ##A   # Generates R/mod_test.R

This might be a bit more messy approach, and does require some serious rearrangement in existing functions. I don't know whether I would recommend this, yet I wanted to throw it out there! :-)

[isaactpetersen]

Are there still plans to support moduleServer() instead of callModule() for Shiny version 1.5 and higher? I'm not sure where to put this, but I just wanted to add my support for this feature.

[ColinFay]

@isaactpetersen it is now supported in {golem} > 0.3.1, if (and only if) you have {shiny} > 1.5.0 installed :)