totole/sapper
1
0
Fork 0
mirror of https://github.com/kevin-DL/sapper.git synced 2026-01-11 19:04:30 +00:00
Code Issues Packages Projects Releases Wiki Activity

site: fix doc hash link destinations (#696)

Browse Source
This commit is contained in:
Conduitry
2019-05-18 15:41:59 -04:00
parent ce50c2ff98
commit 75afc691f4
7 changed files with 12 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
site/content/docs/00-introduction.md
View File

@@ -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

12
site/content/docs/01-structure.md
View File

@@ -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

2
site/content/docs/02-routing.md
View File

@@ -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

2
site/content/docs/03-client-api.md
View File

@@ -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).

2
site/content/docs/04-preloading.md
View File

@@ -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">

2
site/content/docs/13-base-urls.md
View File

@@ -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

2
site/content/migrating/01-migrating.md
View File

@@ -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