10.2 Updating inputs

Three are the key techniques for creating dynamic user interface:

---

1 - update functions

2 - tabsetPanel()

3 - uiOutput() and renderUI()

---

In this first part of the Dynamic UI chapter we will see how to pass from a basic structure to a more complicate one by adding dynamics to the output of the app, calling the “updating functions”.

As we know the basic structure of a Shiny app is made of a UI (user interface) and a Server.

The first example is the User Interface and Server basic structure for updating the app.

############################################
# ui <- fluidPage(
  
#            [id]Input(),
  
#            actionButton()
#       )
 
#############################################

# server <- function(input, output, session) {
  
#           observeEvent(input$... , {
    
#           update[id]Input(inputId = ... , ... = input$... )
#           })  
#           ...
#         }

---

10.2.1 Update functions

The Update function allows you to modify the control after it has been created with a series of [id]Input and update[id]Input, as shown below:

# [id]Input()
# textInput() # ui
# update [....] Input()
# updateTextInput() # server

# numericInput()
# update [....] Input()
# updateNumericInput()

#-------------------------------------
# selectInput()
# update [....] Input()
# updateSelectInput()

# sliderInput()
# update [....] Input()
# updateSliderInput()

Hierarchical, Freezing and Circular references

Other considerations need to be done when requesting the app to update following an interactive input request made by the user.

For example, the selection of natural hierarchy in the data is one of them, and it is important to create a user interface that allows updating the input maintaining stability while dynamically generating changes across multiple categories.

Further considerations involve establishing priorities with the application of key features such as freezing Reactive Inputs, a provided feature to freeze part of the inputs when expected a series of changes and so for establishing priorities and visually summarize data correctly.

# [id]Input()
# tableOutput()

# observeEvent()
# update[id]Input() 

The function update[id]Input() only affects all outputs and observers that have run, for this reason, the freezing function would let you hierarchically updating all your inputs before displaying it.

# [id]Input()
# [some]Output()

# observeEvent()
# freezeReactiveValue() “freezing” the input
# update[id]Input() 

The last consideration for this section is to circularity as seen in many apps, it is created when requested for making simultaneous changes recursively.

In other words, it is seen in apps when updating the input, automatically another input is created in the function of the first one. Under this condition, the cycle can create an recursive loop on the current value of the input bringing it to run again and again in circularity.

How the “Action button” reset the input

A simple example of the use of this command is the Reset button. It is one of the clearest examples of what is meant with making dynamic changes.

When the user interactively intervenes on the app making a choice, then the “reset” button makes it easy to reset the parameters back to their initial value.

# [id]Input()
# actionButton()

# observeEvent()
# update[id]Input()


# [id]Input()
# actionButton()

# observeEvent()
# updateActionButton()

A simple use of the reset input button is shown in this example:

Spring temperature generally varies on average between 19 and 25 C° degrees, let’s set an average value of 21 C° as reset point.

ui <- fluidPage(
  sliderInput("temperature", "Spring temperature", 21, min = 19, max = 25),
  actionButton("reset", "Reset")
)

server <- function(input, output, session) {
  observeEvent(input$reset,{
    updateSliderInput(inputId = "temperature", value = 21)
  })
}

---