fix several typos in code and sentences

action-transfer.Rmd

@@ -322,7 +322,7 @@ There are a couple of other tricks worth knowing about:
       output$report <- downloadHandler(
         filename = "report.html",
         content = function(file) {
-          params <- list(n = input$slider)
+          params <- list(n = input$n)
           callr::r(
             render_report,
             list(input = report_path, output = file, params = params)

reactivity-escaping.Rmd

@@ -204,7 +204,7 @@ server <- function(input, output, session) {
 }
 ```
 
-Notice in this case we can't easily use `observeEvent()` because we perform different actions depending on whether `running()` is `TRUE` or `FALSE`.
+Notice in this case we can't easily use `observeEvent()` because we perform different actions depending on whether `r$running` is `TRUE` or `FALSE`.
 Since we can't use `observeEvent()`, we must use `isolate()` --- if we don't this observer would also take a reactive dependency on `n`, which it updates, so it would get stuck in an infinite loop.
 
 Hopefully these examples start to give you a flavour of what programming with `reactiveValues()` and `observe()` feels like.
@@ -276,7 +276,7 @@ You end up doing a lot of hard work to analyse the flow of events in your app, r
 
 It's informative to compare the two reactive graphs.
 Figure \@ref(fig:anti-pattern) shows the graph from the first example.
-It's misleading because it doesn't look like `nrows` is connected to `df()`.
+It's misleading because it doesn't look like `nrows` is connected to `df`.
 Using a reactive, as in Figure \@ref(fig:pattern), makes the precise connection easy to see.
 Having a reactive graph that is as simple as possible is important for both humans and for Shiny.
 A simple graph is easier for humans to understand, and a simple graph is easier for Shiny to optimise.

reactivity-foundations.Rmd

@@ -436,5 +436,5 @@ Just remember that it's a polite request, not a demand.
 
 ## Summary {#how-it-works}
 
-In this chapter you've learned more about the building blocks that make Shiny work: reactive values, reactive expressions, observers, and timed evaluation.
+In this chapter you've learned more about the building blocks that make Shiny work: reactive values, reactive expressions, observers, and timed invalidation.
 Now we'll turn our attention to a specific combination of reactive values and observers that allows us to escape some of the constraints (for better and worse) of the reactive graph.

reactivity-graph.Rmd

@@ -265,7 +265,7 @@ The neat thing about this process is that Shiny has done the minimum amount of w
 
     ```{r, eval = FALSE}
     x <- reactiveVal(1)
-    y <- reactive(x + y())
+    y <- reactive(x() + y())
     y()
     ```
 

scaling-modules.Rmd

@@ -649,7 +649,7 @@ histogramApp <- function() {
 
   server <- function(input, output, session) {
     data <- datasetServer("data")
-    c(value, name) %<-% selectVarServer("var", data)
+    c(name, value) %<-% selectVarServer("var", data)
     histogramServer("hist", value, name)
   }
   shinyApp(ui, server)
@@ -978,7 +978,7 @@ wizardApp <- function(...) {
 }
 ```
 
-Unfortunately we need to repeat ourselves slightly when using the module, and we need to make sure that the `n` argument to `wizardServer()` is consistent with the `pages` argument to `wizardUi()`.
+Unfortunately we need to repeat ourselves slightly when using the module, and we need to make sure that the `n` argument to `wizardServer()` is consistent with the `pages` argument to `wizardUI()`.
 This is a principled limitation of the module system which we'll discuss in more detail in Section \@ref(module-objects).
 
 Now let's use the wizard in a slightly more realistic app that has inputs and outputs, and yields Figure \@ref(fig:wizard-module).