+
+Astro Actions allow you to define and call backend functions with type-safety. Actions perform data fetching, JSON parsing, and input validation for you. This can greatly reduce the amount of boilerplate needed compared to using an [API endpoint](/en/guides/endpoints/).
+
+Use actions instead of API endpoints for seamless communication between your client and server code and to:
+
+- Automatically validate JSON and form data inputs using [Zod validaton](https://zod.dev/?id=primitives).
+- Generate type-safe functions to call your backend from the client and even [from HTML form actions](#call-actions-from-an-html-form-action). No need for manual `fetch()` calls.
+- Standardize backend errors with the [`ActionError`](/en/reference/api-reference/#actionerror) object.
+
+## Basic usage
+
+Actions are defined in a `server` object exported from `src/actions/index.ts`:
+
+```ts title="src/actions/index.ts"
+import { defineAction } from 'astro:actions';
+import { z } from 'astro:schema';
+
+export const server = {
+ myAction: defineAction({ /* ... */ })
+}
+```
+
+Your actions are available as functions from the `astro:actions` module. Import `actions` and call them client-side within a [UI framework component](/en/guides/framework-components/), [a form POST request](#call-actions-from-an-html-form-action), or by using a `
+```
+
+### Write your first action
+
+Follow these steps to define an action and call it in a `script` tag in your Astro page.
+
+
+
+1. Create a `src/actions/index.ts` file and export a `server` object.
+
+ ```ts title="src/actions/index.ts"
+ export const server = {
+ // action declarations
+ }
+ ```
+
+2. Import the `defineAction()` utility from `astro:actions`, and the `z` object from `astro:schema`.
+
+ ```ts ins={1-2} title="src/actions/index.ts"
+ import { defineAction } from 'astro:actions';
+ import { z } from 'astro:schema';
+
+ export const server = {
+ // action declarations
+ }
+ ```
+
+3. Use the `defineAction()` utility to define a `getGreeting` action. The `input` property will be used to validate input parameters with a [Zod](https://zod.dev) schema and the `handler()` function includes the backend logic to run on the server.
+
+ ```ts ins={5-12} title="src/actions/index.ts"
+ import { defineAction } from 'astro:actions';
+ import { z } from 'astro:schema';
+
+ export const server = {
+ getGreeting: defineAction({
+ input: z.object({
+ name: z.string(),
+ }),
+ handler: async (input) => {
+ return `Hello, ${input.name}!`
+ }
+ })
+ }
+ ```
+
+4. Create an Astro component with a button that will fetch a greeting using your `getGreeting` action when clicked.
+
+ ```astro title="src/pages/index.astro"
+ ---
+ ---
+
+
+
+
+ ```
+
+5. To use your action, import `actions` from `astro:actions` and then call `actions.getGreeting()` in the click handler. The `name` option will be sent to your action’s `handler()` on the server and, if there are no errors, the result will be available as the `data` property.
+
+ ```astro title="src/pages/index.astro" ins={7, 12-13}
+ ---
+ ---
+
+
+
+
+ ```
+
+
+
+See the full Actions API documentation for details on [`defineAction()`](/en/reference/api-reference/#defineaction) and its properties.
+
+## Organizing actions
+
+All actions in your project must be exported from the `server` object in the `src/actions/index.ts` file. You can define actions inline or you can move action definitions to separate files and import them. You can even group related functions in nested objects.
+
+For example, to colocate all of your user actions, you can create a `src/actions/user.ts` file and nest the definitions of both `getUser` and `createUser` inside a single `user` object.
+
+```ts
+// src/actions/user.ts
+import { defineAction } from 'astro:actions';
+
+export const user = {
+ getUser: defineAction(/* ... */),
+ createUser: defineAction(/* ... */),
+}
+```
+
+Then, you can import this `user` object into your `src/actions/index.ts` file and add it as a top-level key to the `server` object alongside any other actions:
+
+```ts title="src/actions/index.ts" ins={1,5}
+import { user } from './user';
+
+export const server = {
+ myAction: defineAction({ /* ... */ }),
+ user,
+}
+```
+
+Now, all of your user actions are callable from the `actions.user` object:
+
+- `actions.user.getUser()`
+- `actions.user.createUser()`
+
+
+## Handling returned data
+
+Actions return an object containing either `data` with the type-safe return value of your `handler()`, or an `error` with any backend errors. Errors may come from validation errors on the `input` property or thrown errors within the `handler()`.
+
+### Checking for errors
+
+It's best to check if an `error` is present before using the `data` property. This allows you to handle errors in advance and ensures `data` is defined without an `undefined` check.
+
+```ts
+const { data, error } = await actions.example();
+
+if (error) {
+ // handle error cases
+ return;
+}
+// use `data`
+```
+
+### Accessing `data` directly without an error check
+
+To skip error handling, for example while prototyping or using a library that will catch errors for you, use the `.orThrow()` property on your action call to throw errors instead of returning an `error`. This will return the action's `data` directly.
+
+This example calls a `likePost()` action that returns the updated number of likes as a `number` from the action `handler`:
+
+```ts ins="orThrow"
+const updatedLikes = await actions.likePost.orThrow({ postId: 'example' });
+// ^ type: number
+```
+
+### Handling backend errors in your action
+
+You can use the provided `ActionError` to throw an error from your action `handler()`, such as "not found" when a database entry is missing, or "unauthorized" when a user is not logged in. This has two main benefits over returning `undefined`:
+
+
+- You can set a status code like `404 - Not found` or `401 - Unauthorized`. This improves debugging errors in both development and in production by letting you see the status code of each request.
+
+- In your application code, all errors are passed to the `error` object on an action result. This avoids the need for `undefined` checks on data, and allows you to display targeted feedback to the user depending on what went wrong.
+
+#### Creating an `ActionError`
+
+To throw an error, import the `ActionError()` class from the `astro:actions` module. Pass it a human-readable status `code` (e.g. `"NOT_FOUND"` or `"BAD_REQUEST"`), and an optional `message` to provide further information about the error.
+
+This example throws an error from a `likePost` action when a user is not logged in, after checking a hypothetical "user-session" cookie for authentication:
+
+```ts title="src/actions/index.ts" ins=/ActionError(?= )/ ins={9-12}
+import { defineAction, ActionError } from "astro:actions";
+import { z } from "astro:schema";
+
+export const server = {
+ likePost: defineAction({
+ input: z.object({ postId: z.string() }),
+ handler: async (input, ctx) => {
+ if (!ctx.cookies.has('user-session')) {
+ throw new ActionError({
+ code: "UNAUTHORIZED",
+ message: "User must be logged in.",
+ });
+ }
+ // Otherwise, like the post
+ },
+ }),
+};
+```
+
+#### Handling an `ActionError`
+
+To handle this error, you can call the action from your application and check whether an `error` property is present. This property will be of type `ActionError` and will contain your `code` and `message`.
+
+In the following example, a `LikeButton.tsx` component calls the `likePost()` action when clicked. If an authentication error occurs, the `error.code` attribute is used to determine whether to display a login link:
+
+```tsx title=src/components/LikeButton.tsx ins="if (error.code === 'UNAUTHORIZED') setShowLogin(true);"
+import { actions } from 'astro:actions';
+import { useState } from 'preact/hooks';
+
+export function LikeButton({ postId }: { postId: string }) {
+ const [showLogin, setShowLogin] = useState(false);
+ return (
+ <>
+ {
+ showLogin && Log in to like a post.
+ }
+
+
+ )
+}
+```
+
+### Handling client redirects
+
+When calling actions from the client, you can integrate with a client-side library like `react-router`, or you can use Astro's [`navigate()` function](/en/guides/view-transitions/#trigger-navigation) to redirect to a new page when an action succeeds.
+
+This example navigates to the homepage after a `logout` action returns successfully:
+
+```tsx title=src/pages/LogoutButton.tsx {2,7-8}
+import { actions } from 'astro:actions';
+import { navigate } from 'astro:transitions/client';
+
+export function LogoutButton() {
+ return (
+
+ );
+}
+```
+
+## Accepting form data from an action
+
+Actions accept JSON data by default. To accept form data from an HTML form, set `accept: 'form'` in your `defineAction()` call:
+
+```ts title="src/actions/index.ts" ins={6}
+import { defineAction } from 'astro:actions';
+import { z } from 'astro:schema';
+
+export const server = {
+ comment: defineAction({
+ accept: 'form',
+ input: z.object(/* ... */),
+ handler: async (input) => { /* ... */ },
+ })
+}
+```
+
+### Validating form data
+
+Actions will parse submitted form data to an object, using the value of each input’s `name` attribute as the object keys. For example, a form containing `` will be parsed to an object like `{ search: 'user input' }`. Your action's `input` schema will be used to validate this object.
+
+To receive the raw `FormData` object in your action handler instead of a parsed object, omit the `input` property in your action definition.
+
+The following example shows a validated newsletter registration form that accepts a user's email and requires a "terms of service" agreement checkbox.
+
+
+
+1. Create an HTML form component with unique `name` attributes on each input:
+
+ ```astro title="src/components/Newsletter.astro" /name="\w+"/
+
+ ```
+
+2. Define a `newsletter` action to handle the submitted form. Validate the `email` field using the `z.string().email()` validator, and the `terms` checkbox using `z.boolean()`:
+
+ ```ts title="src/actions/index.ts" ins={5-12}
+ import { defineAction } from 'astro:actions';
+ import { z } from 'astro:schema';
+
+ export const server = {
+ newsletter: defineAction({
+ accept: 'form',
+ input: z.object({
+ email: z.string().email(),
+ terms: z.boolean(),
+ }),
+ handler: async ({ email, terms }) => { /* ... */ },
+ })
+ }
+ ```
+
+ See the [`input` API reference](/en/reference/api-reference/#input-validator) for all available form validators.
+
+3. Add a `
+ ```
+
+ See [“Call actions from an HTML form action”](#call-actions-from-an-html-form-action) for an alternative way to submit form data.
+
+
+
+### Displaying form input errors
+
+You can validate form inputs before submission using [native HTML form validation attributes](https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_validation#using_built-in_form_validation) like `required`, `type="email"`, and `pattern`. For more complex `input` validation on the backend, you can use the provided [`isInputError()`](/en/reference/api-reference/#isinputerror) utility function.
+
+To retrieve input errors, use the `isInputError()` utility to check whether an error was caused by invalid input. Input errors contain a `fields` object with messages for each input name that failed to validate. You can use these messages to prompt your user to correct their submission.
+
+The following example checks the error with `isInputError()`, then checks whether the error is in the email field, before finally creating a message from the errors. You can use JavaScript DOM manipulation or your preferred UI framework to display this message to users.
+
+```js /isInputError(?= )/ {5-12}
+import { actions, isInputError } from 'astro:actions';
+
+const form = document.querySelector('form');
+const formData = new FormData(form);
+const { error } = await actions.newsletter(formData);
+if (isInputError(error)) {
+ // Handle input errors.
+ if (error.fields.email) {
+ const message = error.fields.email.join(', ');
+ }
+}
+```
+
+## Call actions from an HTML form action
+
+:::note
+Pages must be on-demand rendered when calling actions using a form action. [Ensure prerendering is disabled on the page](/en/guides/server-side-rendering/#opting-out-of-pre-rendering-in-hybrid-mode) before using this API.
+:::
+
+You can enable zero-JS form submissions with standard attributes on any `
+```
+
+### Redirect on action success
+
+To navigate to a different page when an action is successful without client-side JavaScript, you can prepend a path in the `action` attribute.
+
+For example, `action={'/confirmation' + actions.newsletter}` will navigate to `/confirmation` when the `newsletter` action succeeds:
+
+```astro title="src/components/NewsletterSignup.astro" /action=\{[^\{\}]+\}/
+---
+import { actions } from 'astro:actions';
+---
+
+
+```
+
+#### Dynamic redirect on action success
+
+If you need to decide where to redirect to dynamically, you can use an action’s result on the server. A common example is creating a product record and redirecting to the new product's page, e.g. `/products/[id]`.
+
+For example, say you have a `createProduct` action that returns the generated product id:
+
+```ts title="src/actions/index.ts" mark={10}
+import { defineAction } from 'astro:actions';
+import { z } from 'astro:schema';
+
+export const server = {
+ createProduct: defineAction({
+ accept: 'form',
+ input: z.object({ /* ... */ }),
+ handler: async (input) => {
+ const product = await persistToDatabase(input);
+ return { id: product.id };
+ },
+ })
+}
+```
+
+You can retrieve the action result from your Astro component by calling `Astro.getActionResult()`. This returns an object containing `data` or `error` properties when an action is called, or `undefined` if the action was not called during this request.
+
+Use the `data` property to construct a URL to use with `Astro.redirect()`:
+
+```astro title="src/pages/products/create.astro" {4-7}
+---
+import { actions } from 'astro:actions';
+
+const result = Astro.getActionResult(actions.createProduct);
+if (result && !result.error) {
+ return Astro.redirect(`/products/${result.data.id}`);
+}
+---
+
+
+```
+
+### Handle form action errors
+
+Astro will not redirect to your `action` route when an action fails. Instead, the current page is reloaded with any errors the action returned. Calling `Astro.getActionResult()` in the Astro component containing your form gives you access to the `error` object for custom error handling.
+
+The following example displays a general failure message when a `newsletter` action fails:
+
+```astro title="src/pages/index.astro" {4,7-9}
+---
+import { actions } from 'astro:actions';
+
+const result = Astro.getActionResult(actions.newsletter);
+---
+
+{result?.error && (
+
Unable to sign up. Please try again later.
+)}
+
+```
+
+For more customization, you can [use the `isInputError()` utility](#displaying-form-input-errors) to check whether an error is caused by invalid input.
+
+The following example renders an error banner under the `email` input field when an invalid email is submitted:
+
+```astro title="src/pages/index.astro" ins={5,13} ins='aria-describedby="error"'
+---
+import { actions, isInputError } from 'astro:actions';
+
+const result = Astro.getActionResult(actions.newsletter);
+const inputErrors = isInputError(result?.error) ? result.error.fields : {};
+---
+
+
+```
+
+:::note
+Astro persists action `data` and `error` with a single-use cookie. This means `getActionResult()` will return a result on the first request _only_, and `undefined` when revisiting the page.
+:::
+
+#### Preserve input values on error
+
+Inputs will be cleared whenever a form is submitted. To persist input values, you can [enable view transitions](/en/guides/view-transitions/#adding-view-transitions-to-a-page) on the page and apply the `transition:persist` directive to each input:
+
+```astro ins="transition:persist"
+
+```
+
+### Update the UI with a form action result
+
+The result returned by `Astro.getActionResult()` is single-use, and will reset to `undefined` whenever the page is refreshed. This is ideal for [displaying input errors](#handle-form-action-errors) and showing temporary notifications to the user on success.
+
+:::tip
+If you need a result to be displayed across page refreshes, consider storing the result in a database or [in a cookie](/en/reference/api-reference/#astrocookies).
+:::
+
+Pass an action to `Astro.getActionResult()` and use the returned `data` property to render any temporary UI you want to display. This example uses the `productName` property returned by an `addToCart` action to show a success message:
+
+```astro title="src/pages/products/[slug].astro"
+---
+import { actions } from 'astro:actions';
+
+const result = Astro.getActionResult(actions.addToCart);
+---
+
+{result && !result.error && (
+
Added {result.data.productName} to cart
+)}
+
+
+```
+
+:::caution
+Action data is passed using a persisted cookie. **This cookie is not encrypted.** In general, we recommend returning the minimum information required from your action `handler` to avoid vulnerabilities, and persist other sensitive information in a database.
+
+For example, you might return the name of a product in an `addToCart` action, rather than returning the entire `product` object:
+
+```ts title="src/actions/index.ts" del={7} ins={8}
+import { defineAction } from 'astro:actions';
+
+export const server = {
+ addToCard: defineAction({
+ handler: async () => {
+ /* ... */
+ return product;
+ return { productName: product.name };
+ }
+ })
+}
+```
+:::
diff --git a/src/content/docs/en/guides/astro-db.mdx b/src/content/docs/en/guides/astro-db.mdx
index 1234d259811db..97585c02684f7 100644
--- a/src/content/docs/en/guides/astro-db.mdx
+++ b/src/content/docs/en/guides/astro-db.mdx
@@ -7,6 +7,7 @@ i18nReady: true
import { FileTree } from '@astrojs/starlight/components';
import PackageManagerTabs from '~/components/tabs/PackageManagerTabs.astro';
import ReadMore from '~/components/ReadMore.astro';
+import Since from '~/components/Since.astro';
import StudioHeading from '~/components/StudioHeading.astro';
import { Steps } from '@astrojs/starlight/components';
@@ -38,7 +39,7 @@ If you prefer, you can [install `@astrojs/db` manually](/en/guides/integrations-
## Define your database
-Astro DB is a complete solution to configuring, developing and querying your data. A local database is created whenever you run `astro dev`, using LibSQL to manage your data without the need for Docker or a network connection.
+Astro DB is a complete solution to configuring, developing and querying your data. A local database is created whenever you run `astro dev`, using libSQL to manage your data without the need for Docker or a network connection.
Installing `@astrojs/db` with the `astro add` command will create a `db/config.ts` file in your project where you will define your databases tables:
@@ -654,6 +655,68 @@ When you're ready to deploy, see our [Deploy with a Studio Connection guide](#de
+## libSQL
+
+
+
+Astro DB can connect to any libSQL server from any platform that exposes the libSQL remote protocol of the server, or can be self-hosted.
+
+To connect Astro DB to a libSQL database, set the following environment variables:
+- `ASTRO_DB_REMOTE_URL`: the connection URL to your libSQL server
+- `ASTRO_DB_APP_TOKEN`: the auth token to your libSQL server
+
+The [commands for deploying and pushing changes](#deploy-with-a-studio-connection) to your database are the same when using libSQL as when connecting to an Astro Studio hosted database. However, both of your environment variables need to be set locally when running commands with the `--remote` option like `astro build` and `astro db push`.
+
+Details of the libSQL connection (e.g. encryption key, replication, sync interval) can be configured as query parameters in the remote connection URL.
+
+For example, to have a local file work as an embedded replica to an encrypted libSQL server, you can set the following environment variables:
+
+```env title=".env"
+ASTRO_DB_REMOTE_URL=file://local-copy.db?encryptionKey=your-encryption-key&syncInterval=60&syncUrl=libsql%3A%2F%2Fyour.server.io
+ASTRO_DB_APP_TOKEN=token-to-your-remote-url
+```
+
+### URL scheme and host
+
+libSQL supports both HTTP and WebSockets as the transport protocol for a remote server. It also supports using a local file or an in-memory DB. Those can be configured using the following URL schemes in the connection URL:
+
+- `memory:` will use an in-memory DB. The host must be empty in this case.
+- `file:` will use a local file. The host is the path to the file (`file:path/to/file.db`).
+- `libsql:` will use a remote server through the protocol preferred by the library (this might be different across versions). The host is the address of the server (`libsql://your.server.io`).
+- `http:` will use a remote server through HTTP. `https:` can be used to enable a secure connection. The host is the same as for `libsql:`.
+- `ws:` will use a remote server through WebSockets. `wss:` can be used to enable a secure connection. The host is the same as for `libsql:`.
+
+### `encryptionKey`
+
+libSQL has native support for encrypted databases. Passing this search parameter will enable encryption using the given key:
+
+```env title=".env"
+ASTRO_DB_REMOTE_URL=file:path/to/file.db?encryptionKey=your-encryption-key
+```
+
+### `syncUrl`
+
+Embedded replicas are a feature of libSQL clients that enables a full synchronized copy of your database on a local file or in memory for ultra-fast reads. Writes are sent to a remote database defined on the `syncUrl` and synchronized with the local copy.
+
+Use this property to pass a separate connection URL to turn the DB into an embedded replica of another database. This should only be used with the schemes `file:` and `memory:`. The parameter must be URL encoded.
+
+For example, to have an in-memory embedded replica of a database on `libsql://your.server.io`, you can set the connection URL as such:
+
+```env title=".env"
+ASTRO_DB_REMOTE_URL=memory:?syncUrl=libsql%3A%2F%2Fyour.server.io
+```
+
+### `syncInterval`
+
+Interval between embedded replicas synchronizations in seconds. By default it only synchronizes on startup and after writes.
+
+This property is only used when `syncUrl` is also set. For example, to set an in-memory embedded replica to synchronize every minute set the following environment variable:
+
+```env title=".env"
+ASTRO_DB_REMOTE_URL=memory:?syncUrl=libsql%3A%2F%2Fyour.server.io&syncInterval=60
+```
+
+
## Building Astro DB integrations
[Astro integrations](/en/reference/integrations-reference/) can extend user projects with additional Astro DB tables and seed data.
@@ -752,4 +815,3 @@ Additionally, [pushing any table schema changes](#pushing-table-schemas) (also k
:::danger
If you override your `.db` file on deployment, you will lose your production data. Follow the deployment method process for your host carefully to prevent data loss.
:::
-
diff --git a/src/content/docs/en/guides/internationalization.mdx b/src/content/docs/en/guides/internationalization.mdx
index b543e2f53d673..b005c14790943 100644
--- a/src/content/docs/en/guides/internationalization.mdx
+++ b/src/content/docs/en/guides/internationalization.mdx
@@ -286,13 +286,22 @@ With the above configuration:
The above URLs will also be returned by the `getAbsoluteLocaleUrl()` and `getAbsoluteLocaleUrlList()` functions.
-## `fallback`
+## Fallback
-Astro's i18n routing allows you to configure a **fallback routing strategy**. When a page in one language doesn't exist (e.g. a page that is not yet translated), instead of displaying a 404 page, you can redirect a user from one locale to another on a per-language basis. This is useful when you do not yet have a page for every route, but you want to still provide some content to your visitors.
+When a page in one language doesn't exist (e.g. a page that is not yet translated), instead of displaying a 404 page, you can choose to display fallback content from another `locale` on a per-language basis. This is useful when you do not yet have a page for every route, but you want to still provide some content to your visitors.
-For example, the configuration below sets `es` as the fallback locale for any missing `fr` routes. This means that a user visiting `example.com/fr/my-page/` will be redirected to and shown the content for `example.com/es/my-page/` instead of being taken to a 404 page when `src/pages/fr/my-page.astro` does not exist.
+Your fallback strategy consists of two parts: choosing which languages should fallback to which other languages ([`i18n.fallback`](/en/reference/configuration-reference/#i18nfallback)) and choosing whether to perform a [redirect](/en/guides/routing/#redirects) or a [rewrite](/en/guides/routing/#rewrites) to show the fallback content ([`i18n.routing.fallbackType`](/en/reference/configuration-reference/#i18nroutingfallbacktype) added in Astro v4.15.0).
-```js title="astro.config.mjs" ins={6-8}
+For example, when you configure `i18n.fallback: { fr: "es" }`, Astro will ensure that a page is built in `src/pages/fr/` for every page that exists in `src/pages/es/`.
+
+If any page does not already exist, then a page will be created depending on your `fallbackType`:
+
+- With a redirect to the corresponding `es` route (default behavior).
+- With the content of the `/es/` page (`i18n.routing.fallbackType: "rewrite"`).
+
+For example, the configuration below sets `es` as the fallback locale for any missing `fr` routes. This means that a user visiting `example.com/fr/my-page/` will be shown the content for `example.com/es/my-page/` (without being redirected) instead of being taken to a 404 page when `src/pages/fr/my-page.astro` does not exist.
+
+```js title="astro.config.mjs" ins={6-8,10}
import { defineConfig } from "astro/config"
export default defineConfig({
i18n: {
@@ -300,13 +309,14 @@ export default defineConfig({
locales: ["es", "en", "fr"],
fallback: {
fr: "es"
+ },
+ routing: {
+ fallbackType: "rewrite"
}
}
})
```
-Astro will ensure that a page is built in `src/pages/fr` for every page that exists in `src/pages/es/`. If the page does not already exist, then a page with a redirect to the corresponding `es` route will be created.
-
## Custom locale paths
In addition to defining your site's supported `locales` as strings (e.g. "en", "pt-br"), Astro also allows you to map an arbitrary number of [browser-recognized language `codes`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Language#syntax) to a custom URL `path`. While locales can be strings of any format as long as they correspond to your project folder structure, `codes` must follow the browser's accepted syntax.
diff --git a/src/content/docs/en/guides/view-transitions.mdx b/src/content/docs/en/guides/view-transitions.mdx
index 75d10a0983e07..57648267d1a07 100644
--- a/src/content/docs/en/guides/view-transitions.mdx
+++ b/src/content/docs/en/guides/view-transitions.mdx
@@ -328,8 +328,8 @@ The following example shows an Astro component that navigates a visitor to anoth
import { navigate } from 'astro:transitions/client';
// Navigate to the selected option automatically.
- document.querySelector('select').onchange = (ev) => {
- let href = ev.target.value;
+ document.querySelector('select').onchange = (event) => {
+ let href = event.target.value;
navigate(href);
};
@@ -572,9 +572,9 @@ Here is an example of using the `astro:before-preparation` event to load a spinn
```js
```
@@ -634,14 +634,44 @@ At this point of the lifecycle, you could choose to define your own swap impleme
```astro
```
+#### Building a custom swap function
+
+
+
+The `swapFunction` object of the `astro:transitions/client` module provides five utility functions that handle specific swap-related tasks, including handling document attributes, page elements, and script execution. These functions can be used directly to define a custom swap implementation.
+
+The following example demonstrates how to use these functions to recreate Astro's built-in swap implementation:
+
+```astro
+