Fix broken links

action-tidy.Rmd

@@ -448,7 +448,7 @@ If you have no idea what this combination is, you can skip this section, but if
 It's a tempting approach because it requires learning very few new ideas.
 But it has some major downsides: because you are pasting strings together, it's very easy to accidentally create invalid code, or code that can be abused to do something that you didn't want.
 This isn't super important if it's a Shiny app that only you use, but it isn't a good habit to get into --- otherwise it's very easy to accidentally create a security hole in an app that you share more widely.
-We'll come back that idea in Chapter \@ref(scaling-safety).
+We'll come back that idea in Chapter \@ref(scaling-security).
 
 (You shouldn't feel bad if this is the only way you can figure out to solve a problem, but when you have a bit more mental space, I'd recommend spending some time figuring out how to do it without string manipulation. This will help you to become a better R programmer.)
 

basic-reactivity.Rmd

@@ -53,7 +53,7 @@ This is why almost all of the reactive programming you'll do in Shiny will be in
 
 [^basic-reactivity-2]: The primary exception is where there's some work that can be shared across multiple users.
     For example, all users might be looking at the same large csv file, so you might as well load it once and share it between users.
-    We'll come back to that idea in Section \@ref(data-import).
+    We'll come back to that idea in Section \@ref(schedule-data-munging).
 
 Server functions take three parameters: `input`, `output`, and `session`.
 Because you never call the server function yourself, you'll never create these objects yourself.

reactivity-graph.Rmd

@@ -22,7 +22,7 @@ Recall that reactive inputs and expressions are collectively called reactive pro
 
 [^reactivity-graph-1]: Anywhere you see output, you can also think observer.
     The primary difference is that certain outputs that aren't visible will never be computed.
-    We'll discuss the details in Section \@ref(outputs-adv)
+    We'll discuss the details in Section \@ref(observers-details).
 
 ```{r graph-complete, echo = FALSE, out.width = NULL, fig.cap = "Complete reactive graph of an imaginary app containing three inputs, three reactive expressions, and three outputs."}
 knitr::include_graphics("diagrams/reactivity-tracking/08.png", dpi = 300)

scaling-testing.Rmd

@@ -11,7 +11,7 @@ Testing is a way to capture desired behaviour of your code, in such a way that y
 Turning your existing informal tests into code is painful when you first do it, because you need to carefully turn every key press and mouse click into a line of code, but once done, it's tremendously faster to re-run your tests.
 
 We'll perform automated testing with the [testthat](http://testthat.r-lib.org/) package.
-testthat requires turning your app into a package, but as discussed in Chapter \@ref(package), this is not too much work, and I think pays off for other reasons.
+testthat requires turning your app into a package, but as discussed in Chapter \@ref(scaling-packaging), this is not too much work, and I think pays off for other reasons.
 
 A testthat test looks like this: