Change in behaviour with modules between 0.4.0 and 0.4.1

[richfitz]

We have noticed a change in behaviour when using shinyAce in a module and would like to know if this is a bug or a change in behaviour that we can rely on in future versions.

This code:

mod_ui <- function(id) {
  ns <- shiny::NS(id)
  shinyAce::aceEditor(ns("editor"), mode = "r", readOnly = TRUE)
}

mod_server <- function(input, output, session) {
  code <- "a <- 1\nb <- 2"
  shinyAce::updateAceEditor(session, session$ns("editor"), code) # <= 0.4.0
}

ui <- function() {
  shiny::shinyUI(mod_ui("my"))  
}

server <- function(input, output, session) {
  mod <- callModule(mod_server, "my")
}

shiny::shinyApp(ui, server)

in versions 0.4.0 and below will display 2 lines of code. In 0.4.1 it displays nothing (no call to updateAceEditor in this fashion works).

If that line is changed to

shinyAce::updateAceEditor(session, "editor", code)

(i.e., dropping the ns) then the code is displayed in versions 0.4.1 and not in 0.4.0

This is with shiny 1.4.0 and R 3.6.1

[GregorDeCillia]

Normally, it should not be necessary to use ns() inside the server part of modules (except for modules that use renderUI()). Therefore, I would consider the new behavior as the correct implementation of updateAceEditor(). It is also in line with the way updateTextInput() and other update functions from the shiny:: namespace are implemented.

[vnijs]

I don't use modules much myself so don't have much to add here. Thanks for the comment @GregorDeCillia. @dgkf and @detule updated how shinyAce works with modules so they may want to comments also.

[richfitz]

Great, thanks for the rapid feedback - this is very useful.

[dgkf]

I agree with @GregorDeCillia. This is aligned with the shiny::callModule behavior of specifying modules with their bare name (as opposed to ns(<name>)). As mentioned, the only time ns() is typically used is within ui functions (or ui's generated within a server function via renderUI).

I can't speak to the direction of the package, but do believe that this behavior is better aligned with idiomatic Shiny module development practices.

[vnijs]

The lack of reported issues suggests this is working as expected. Please reopen if needed.