Shiny Text Output

[michaelgloven]

how do i show the label value rather than code as a text output:

library(shiny)

ui <- fluidPage(
  selectInput("mode","Mode", choices = "", multiple = F,  width = "250px"),
  h5(textOutput("text")),
)

server <- function(input, output, session) {
  
shiny::observe({
            modes <- c("A" = 1, "B" = 2, "C" = 3)
            updateSelectInput(session = session, inputId = "mode", choices = modes, selected = 1)
           })
  output$text <- renderText({paste(" Mode = ", input$mode)
  })

}


shinyApp(ui = ui, server = server)

[FJCC]

You can do a horrible hack like the code below, but what is the larger problem you are trying to solve?

library(shiny)

ui <- fluidPage(
  selectInput("mode","Mode", choices = "", multiple = F,  width = "250px"),
  h5(textOutput("text")),
)

server <- function(input, output, session) {
  
    modes <- c("A" = 1, "B" = 2, "C" = 3)
  shiny::observe({
    updateSelectInput(session = session, inputId = "mode", choices = modes, selected = 1)
  })
  output$text <- renderText({paste(" Mode = ", names(modes)[which(modes == input$mode)])
  })
  
}


shinyApp(ui = ui, server = server)

[michaelgloven]

thanks for your reply

most of my select inputs are code lists and my objective is to return human readable selections back to the end user in certain parts of my application UI. So, if a user selects "Mode" = "A" I want them to see A later on in the application workflow and not the code 1 as they do not know what this means. Further, all my lists use code lists as it simplifies my server code and allows for easy changing of user selectable lists. I'm open to changing this design but its worked well for me the last couple years. Bottom line this is a UI requirement that helps application users see what they've picked when me as the designer uses code lists.

Given I have more than 50 lists I thought there might be a more elegant solution, unless I'm not following a best practice

[nirgrahamuk]

There are very rare use cases to have observes creates renderfunction hooks; the typical case should be that renderfunctions are simply defined at the top level, and your code provides the inputs, and it works. Also reusable data elements, like the currently active name associated with the selected mode, can become reactive elements in their own right, so you can reuse them wherever they are needed reducing code duplications and gaining the benefits of modularity.
Perhaps you have usecase where update* on your controls has to be frequent but in this example at least its superflous, as the update* needs to only be set one time, so I cleaned up that up also here.

  library(shiny)

ui <- fluidPage(
  selectInput("mode","Mode", choices = "", multiple = F,  width = "250px"),
  h5(textOutput("text")),
)

server <- function(input, output, session) {
  
  modes <- c("A" = 1, "B" = 2, "C" = 3)
  
  #in this example its only needed to set the input$mode exactly once ... 
  updateSelectInput(session = session, inputId = "mode", choices = modes, selected = 1)

  active_mode_name <- reactive({
    names(modes)[which(modes == req(input$mode))]
    })
  
  output$text <- renderText({paste(" Mode = ", active_mode_name())})
}


shinyApp(ui = ui, server = server)