Routing
此内容尚不支持你的语言。
Astro uses file-based routing to generate your build URLs based on the file layout of your project src/pages/
directory.
Navigating between pages
Section titled Navigating between pagesAstro uses standard HTML <a>
elements to navigate between routes. There is no framework-specific <Link>
component provided.
Static routes
Section titled Static routes.astro
page components as well as Markdown and MDX Files (.md
, .mdx
) within the src/pages/
directory automatically become pages on your website. Each page’s route corresponds to its path and filename within the src/pages/
directory.
There is no separate “routing config” to maintain in an Astro project! When you add a file to the src/pages/
directory, a new route is automatically created for you. In static builds, you can customize the file output format using the build.format
configuration option.
Dynamic routes
Section titled Dynamic routesAn Astro page file can specify dynamic route parameters in its filename to generate multiple, matching pages. For example, src/pages/authors/[author].astro
generates a bio page for every author on your blog. author
becomes a parameter that you can access from inside the page.
In Astro’s default static output mode, these pages are generated at build time, and so you must predetermine the list of author
s that get a corresponding file. In SSR mode, a page will be generated on request for any route that matches.
Static (SSG) Mode
Section titled Static (SSG) ModeBecause all routes must be determined at build time, a dynamic route must export a getStaticPaths()
that returns an array of objects with a params
property. Each of these objects will generate a corresponding route.
[dog].astro
defines the dynamic dog
parameter in its filename, so the objects returned by getStaticPaths()
must include dog
in their params
. The page can then access this parameter using Astro.params
.
This will generate three pages: /dogs/clifford
, /dogs/rover
, and /dogs/spot
, each displaying the corresponding dog name.
The filename can include multiple parameters, which must all be included in the params
objects in getStaticPaths()
:
This will generate /en-v1/info
and /fr-v2/info
.
Parameters can be included in separate parts of the path. For example, the file src/pages/[lang]/[version]/info.astro
with the same getStaticPaths()
above will generate the routes /en/v1/info
and /fr/v2/info
.
📚 Learn more about getStaticPaths()
.
Rest parameters
Section titled Rest parametersIf you need more flexibility in your URL routing, you can use a rest parameter ([...path]
) in your .astro
filename to match file paths of any depth:
This will generate /sequences/one/two/three
, /sequences/four
, and /sequences
. (Setting the rest parameter to undefined
allows it to match the top level page.)
Rest parameters can be used with other named parameters. For example, GitHub’s file viewer can be represented with the following dynamic route:
In this example, a request for /withastro/astro/tree/main/docs/public/favicon.svg
would be split into the following named parameters:
Example: Dynamic pages at multiple levels
Section titled Example: Dynamic pages at multiple levelsIn the following example, a rest parameter ([...slug]
) and the props
feature of getStaticPaths()
generate pages for slugs of different depths.
Server (SSR) Mode
Section titled Server (SSR) ModeIn SSR mode, dynamic routes are defined the same way: include [param]
or [...path]
brackets in your file names to match arbitrary strings or paths. But because the routes are no longer built ahead of time, the page will be served to any matching route. Since these are not “static” routes, getStaticPaths
should not be used.
This page will be served for any value of resource
and id
: resources/users/1
, resources/colors/blue
, etc.
Modifying the [...slug]
example for SSR
Section titled Modifying the [...slug] example for SSRBecause SSR pages can’t use getStaticPaths()
, they can’t receive props. The previous example can be adapted for SSR mode by looking up the value of the slug
param in an object. If the route is at the root (”/”), the slug param will be undefined
. If the value doesn’t exist in the object, we redirect to a 404 page.
Redirects
Section titled RedirectsSometimes you will need to redirect your readers to a new page, either permanently because your site structure has changed or in response to an action such as logging in to an authenticated route.
You can define rules to redirect users to permanently-moved pages in your Astro config. Or, redirect users dynamically as they use your site.
Configured Redirects
Section titled Configured Redirectsastro@2.9.0
You can specify a mapping of permanent redirects in your Astro config with the redirects
value. For most redirects, this is a mapping of an old route to the new route:
These redirects follow the same rules as file-based routes. Dynamic routes are allowed as long as both the new and old routes contain the same parameters, for example:
Using SSR or a static adapter, you can also provide an object as the value, allowing you to specify the status
code in addition to the new destination
:
When running astro build
, Astro will output HTML files with the meta refresh tag by default. Supported adapters will instead write out the host’s configuration file with the redirects.
The status code is 301
by default. If building to HTML files the status code is not used by the server.
Dynamic redirects
Section titled Dynamic redirectsOn the Astro
global, the Astro.redirect
method allows you to redirect to another page dynamically. You might do this after checking if the user is logged in by getting their session from a cookie.
Route Priority Order
Section titled Route Priority OrderIt’s possible for multiple routes to match the same URL path. For example each of these routes would match /posts/create
:
目錄src/pages/
目錄posts/
- create.astro
- [pid].astro
- […slug].astro
Astro needs to know which route should be used to build the page. To do so, it sorts them according to the following rules:
- Static routes without path parameters will take precedence over all other routes
- Dynamic routes using named parameters take precedence over rest parameters
- Pre-rendered dynamic routes take precedence over server dynamic routes
- Rest parameters have the lowest priority
- Endpoints always take precedence over pages
- Ties are resolved alphabetically
Given the example above, here are a few examples of how the rules will match a requested URL to the route used to build the HTML:
pages/posts/create.astro
- Will build/posts/create
pages/posts/[pid].astro
- Will build/posts/1
,/posts/abc
, etc. But not/posts/create
pages/posts/[...slug].astro
- Will build/posts/1/2
,/posts/a/b/c
, etc. But not/posts/create
,/posts/1
,/posts/abc
Redirects also follow the same rules, but are prioritized last; if there is a file-based route and a redirect with the same route priority level, the file-based route is chosen.
Pagination
Section titled PaginationAstro supports built-in pagination for large collections of data that need to be split into multiple pages. Astro will generate common pagination properties, including previous/next page URLs, total number of pages, and more.
Paginated route names should use the same [bracket]
syntax as a standard dynamic route. For instance, the file name /astronauts/[page].astro
will generate routes for /astronauts/1
, /astronauts/2
, etc, where [page]
is the generated page number.
You can use the paginate()
function to generate these pages for an array of values like so:
This generates the following pages, with 2 items to a page:
/astronauts/1
- Page 1: Displays “Neil Armstrong” and “Buzz Aldrin”/astronauts/2
- Page 2: Displays “Sally Ride” and “John Glenn”
The page
prop
Section titled The page propWhen you use the paginate()
function, each page will be passed its data via a page
prop. The page
prop has many useful properties, but here are the highlights:
- page.data - array containing the page’s slice of data that you passed to the
paginate()
function - page.url.next - link to the next page in the set
- page.url.prev - link to the previous page in the set
Complete API reference
Section titled Complete API referenceNested Pagination
Section titled Nested PaginationA more advanced use-case for pagination is nested pagination. This is when pagination is combined with other dynamic route params. You can use nested pagination to group your paginated collection by some property or tag.
For example, if you want to group your paginated Markdown posts by some tag, you would use nested pagination by creating a /src/pages/[tag]/[page].astro
page that would match the following URLS:
/red/1
(tag=red)/red/2
(tag=red)/blue/1
(tag=blue)/green/1
(tag=green)
Nested pagination works by returning an array of paginate()
results from getStaticPaths()
, one for each grouping.
In the following example, we will implement nested pagination to build the URLs listed above:
Excluding pages
Section titled Excluding pagesYou can exclude pages or directories from being built by prefixing their names with an underscore (_
). Files with the _
prefix won’t be recognized by the router and won’t be placed into the dist/
directory.
You can use this to temporarily disable pages, and also to put tests, utilities, and components in the same folder as their related pages.
In this example, only src/pages/index.astro
and src/pages/posts/post1.md
will be built as page routes and HTML files.
目錄src/pages/
目錄_hidden-directory/
- page1.md
- page2.md
- _hidden-page.astro
- index.astro
目錄posts/
- _SomeComponent.astro
- _utils.js
- post1.md