site: fix doc hash link destinations (#696)

Conduitry · Conduitry · commit 75afc691f4b4 · 2019-05-18T15:41:59.000-04:00
diff --git a/site/content/docs/00-introduction.md b/site/content/docs/00-introduction.md
@@ -32,7 +32,7 @@ For web developers, the stakes are generally lower than for combat engineers. Bu
 [Next.js](https://github.com/zeit/next.js) is a React framework from [Zeit](https://zeit.co), and is the inspiration for Sapper. There are a few notable differences, however:
 
 * Sapper is powered by Svelte instead of React, so it's faster and your apps are smaller
-* Instead of route masking, we encode route parameters in filenames (see the [routing](docs#routing) section below)
+* Instead of route masking, we encode route parameters in filenames (see the [routing](docs#Routing) section below)
 * As well as *pages*, you can create *server routes* in your `src/routes` directory. This makes it very easy to, for example, add a JSON API such as the one powering this very page (try visiting [/docs.json](/docs.json))
 * Links are just `<a>` elements, rather than framework-specific `<Link>` components. That means, for example, that [this link right here](/), despite being inside a blob of markdown, works with the router as you'd expect
 
diff --git a/site/content/docs/01-structure.md b/site/content/docs/01-structure.md
@@ -24,9 +24,9 @@ If you take a look inside the [sapper-template](https://github.com/sveltejs/sapp
 
 When you first run Sapper, it will create an additional `__sapper__` directory containing generated files.
 
-You'll notice a few extra files and a `cypress` directory which relates to [testing](docs#testing) — we don't need to worry about those right now.
+You'll notice a few extra files and a `cypress` directory which relates to [testing](docs#Testing) — we don't need to worry about those right now.
 
-> You *can* create these files from scratch, but it's much better to use the template. See [getting started](docs#getting-started) for instructions on how to easily clone it
+> You *can* create these files from scratch, but it's much better to use the template. See [getting started](docs#Getting_started) for instructions on how to easily clone it
 
 
 ### package.json
@@ -35,9 +35,9 @@ Your package.json contains your app's dependencies and defines a number of scrip
 
 * `npm run dev` — start the app in development mode, and watch source files for changes
 * `npm run build` — build the app in production mode
-* `npm run export` — bake out a static version, if applicable (see [exporting](docs#exporting))
+* `npm run export` — bake out a static version, if applicable (see [exporting](docs#Exporting))
 * `npm start` — start the app in production mode after you've built it
-* `npm test` — run the tests (see [testing](docs#testing))
+* `npm test` — run the tests (see [testing](docs#Testing))
 
 
 ### src
@@ -56,7 +56,7 @@ sapper.start({
 });
 ```
 
-In many cases, that's the entirety of your entry module, though you can do as much or as little here as you wish. See the [client API](docs#client-api) section for more information on functions you can import.
+In many cases, that's the entirety of your entry module, though you can do as much or as little here as you wish. See the [client API](docs#Client_API) section for more information on functions you can import.
 
 
 #### src/server.js
@@ -88,7 +88,7 @@ Because every app needs a slightly different service worker (sometimes it's appr
 
 This file is a template for responses from the server. Sapper will inject content that replaces the following tags:
 
-* `%sapper.base%` — a `<base>` element (see [base URLs](docs#base-urls))
+* `%sapper.base%` — a `<base>` element (see [base URLs](docs#Base_URLs))
 * `%sapper.styles%` — critical CSS for the page being requested
 * `%sapper.head%` — HTML representing page-specific `<head>` contents, like `<title>`
 * `%sapper.html%` — HTML representing the body of the page being rendered
diff --git a/site/content/docs/02-routing.md b/site/content/docs/02-routing.md
@@ -70,7 +70,7 @@ Dynamic parameters are encoded using `[brackets]`. For example, here's how you c
 </div>
 ```
 
-> See the section on [preloading](docs#preloading) for more info about `preload` and `this.fetch`
+> See the section on [preloading](docs#Preloading) for more info about `preload` and `this.fetch`
 
 
 ### Server routes
diff --git a/site/content/docs/03-client-api.md b/site/content/docs/03-client-api.md
@@ -36,7 +36,7 @@ Programmatically navigates to the given `href`. If the destination is a Sapper r
 
 * `href` — the page to prefetch
 
-Programmatically prefetches the given page, which means a) ensuring that the code for the page is loaded, and b) calling the page's `preload` method with the appropriate options. This is the same behaviour that Sapper triggers when the user taps or mouses over an `<a>` element with [rel=prefetch](docs#prefetching).
+Programmatically prefetches the given page, which means a) ensuring that the code for the page is loaded, and b) calling the page's `preload` method with the appropriate options. This is the same behaviour that Sapper triggers when the user taps or mouses over an `<a>` element with [rel=prefetch](docs#Prefetching).
 
 
 
diff --git a/site/content/docs/04-preloading.md b/site/content/docs/04-preloading.md
@@ -2,7 +2,7 @@
 title: Preloading
 ---
 
-As seen in the [routing](docs#routing) section, page components can have an optional `preload` function that will load some data that the page depends on. This is similar to `getInitialProps` in Next.js or `asyncData` in Nuxt.js.
+As seen in the [routing](docs#Routing) section, page components can have an optional `preload` function that will load some data that the page depends on. This is similar to `getInitialProps` in Next.js or `asyncData` in Nuxt.js.
 
 ```html
 <script context="module">
diff --git a/site/content/docs/13-base-urls.md b/site/content/docs/13-base-urls.md
@@ -21,7 +21,7 @@ express() // or Polka, or a similar framework
 
 Sapper will detect the base path and configure both the server-side and client-side routers accordingly.
 
-If you're [exporting](docs#exporting) your app, you will need to tell the exporter where to begin crawling:
+If you're [exporting](docs#Exporting) your app, you will need to tell the exporter where to begin crawling:
 
 ```bash
 sapper export --basepath my-base-path
diff --git a/site/content/migrating/01-migrating.md b/site/content/migrating/01-migrating.md
@@ -292,7 +292,7 @@ Once your `App.html` has been created and your server and client apps updated, y
 
 ##### app/template.html
 
-* Your `<head>` element must contain `%sapper.base%` (see ([base URLs](docs#base-urls))
+* Your `<head>` element must contain `%sapper.base%` (see ([base URLs](docs#Base_URLs))
 * Remove references to your service worker; this is now handled by `%sapper.scripts%`
 
 ##### Pages

Original file line number	Diff line number	Diff line change
@@ -36,7 +36,7 @@ Programmatically navigates to the given `href`. If the destination is a Sapper r
`36`	`36`
`37`	`37`	* `href` — the page to prefetch
`38`	`38`
`39`		-Programmatically prefetches the given page, which means a) ensuring that the code for the page is loaded, and b) calling the page's `preload` method with the appropriate options. This is the same behaviour that Sapper triggers when the user taps or mouses over an `<a>` element with [rel=prefetch](docs#prefetching).
	`39`	+Programmatically prefetches the given page, which means a) ensuring that the code for the page is loaded, and b) calling the page's `preload` method with the appropriate options. This is the same behaviour that Sapper triggers when the user taps or mouses over an `<a>` element with [rel=prefetch](docs#Prefetching).
`40`	`40`
`41`	`41`
`42`	`42`