Update reactivity-motivation.Rmd with minor typo (#615)

reactivity-motivation.Rmd

@@ -26,7 +26,7 @@ This is quite different from most R code, which typically deals with fairly stat
 
 For Shiny apps to be maximally useful, we need reactive expressions and outputs to update if and only if their inputs change.
 We want outputs to stay in sync with inputs, while ensuring that we never do more work than necessary.
-To see why reactivity is so helpful here, we'll take a stab a solving a simple problem without reactivity.
+To see why reactivity is so helpful here, we'll take a stab at solving a simple problem without reactivity.
 
 ### Why can't you use variables?
 

scaling-functions.Rmd

@@ -278,8 +278,8 @@ This doesn't make testing or debugging any easier, but it does reduce duplicated
 We could of course add `session` to the arguments of the function:
 
 ```{r}
-switch_page <- function(i) {
-  updateTabsetPanel(input = "wizard", selected = paste0("page_", i))
+switch_page <- function(i, session) {
+  updateTabsetPanel(session = session, input = "wizard", selected = paste0("page_", i))
 }
 
 server <- function(input, output, session) {

scaling-modules.Rmd

@@ -175,7 +175,7 @@ The difference is largely superficial for this simple app, but `moduleServer()`
 Now that we have a complete app, let's circle back and talk about namespacing some more.
 The key idea that makes modules work is that the name of each control (i.e. its `id`) is now determined by two pieces:
 
--   The first piece comes from the module **user**, the developer who calls `histogramServer()`.
+-   The first piece comes from the module **user**, the developer who calls `histogramUI()`.
 -   The second piece comes from the module **author**, the developer who wrote `histogramServer()`.
 
 This two-part specification means that you, the module author, don't need to worry about clashing with other UI components created by the user.