Remote Functions

[dummdidumm]

The RFC was tweaked, see #13897 (comment) for a list of changes

tl;dr

Remote functions are a new concept in SvelteKit that allow you to declare functions inside a .remote.ts file, import them inside Svelte components and call them like regular functions. On the server they work like regular functions (and can access environment variables and database clients and so on), while on the client they become wrappers around fetch. If you're familiar with RPC and 'server functions', this is basically our take on the concept, that addresses some of the drawbacks we've encountered with other implementations of the idea.

You can try it out soon by installing from the corresponding PR once it's out...

... and add the experimental options

const config = {
	// ...

	kit: {
		// add this:
		experimental: {
			remoteFunctions: true
		},
		// ...
	},

	// we recommend using this in combination with Svelte's new async capabilities
	compilerOptions: {
		experimental: { async: true }
	}
};

We'll also link an example here, soon.

Background

Today, SvelteKit's data loading is based on the concept of loaders. You declare a load function inside a +page/layout(.server).ts file, fetch the required data for the whole page in it, and retrieve the result via the data prop inside the sibling +page/layout.svelte file.

This allows for a very structured approach to data loading and works well for sites where the loaded data is used on the whole page. When that isn't so clear-cut, some drawbacks become apparent:

• it leads to implicit coupling between what seem like disconnected files:
  • colocation suffers
  • data only needed in one corner of the page, or only under certain conditions, still needs to be put into the loader
  • deleting or refactoring code becomes harder since you need to keep in mind both where stuff is loaded and where it’s used
• sharing data means moving its data loading up and down the layout loader tree, leading to more complexity
• refetching data happens on a loader level, if you want it to be more granular SvelteKit can't help you

Additionally, since load and the resulting data prop are somewhat disconnected, we have to resort to very clever but somewhat weird solutions like generating hidden types you import as ./$types or even using a TypeScript plugin to avoid having to import the types yourself. An approach where we can use TypeScript natively would simplify all this and make it more robust.

Lastly, apart from form actions SvelteKit doesn't give you a good way to mutate data. You can use +server.ts files and do fetch requests against these endpoints, but it's a lot of ceremony and you lose type safety.

Asynchronous Svelte

A couple of weeks ago we introduced Asynchronous Svelte, a proposal to allow using await at the top level of Svelte components and inside the template.

This in itself is already valuable, but the way SvelteKit's data loading is architected right now you can't take full advantage of it inside SvelteKit.

Requirements

A solution should fix these drawbacks and take advantage of Svelte's capabilities, and specifically should:

• be secure and intuitive
• increase colocation, moving data loading closer to where it's used
• make loading and mutation type-safe
• put control of granularity in the developer's hands
• fully take advantage of asynchronous Svelte
• be maximally efficient

An important additional requirement is that modules that can run in the client (including components) must never include code that can only run on the server. A remote function must be able to safely access things like database clients and environment variables that should not (or cannot) be accessed from the client.

In practice, this means that remote functions must be declared in a separate module. Over the last few years various systems have experimented with 'server functions' declared alongside universal/client code, and we're relieved to see a growing consensus that this is a flawed approach that trades security and clarity for a modicum of convenience. You're one innocent mistake away from leaking sensitive information (such as API keys or the shape of your database), and even if tooling successfully treeshakes it away, it may remain in sourcemaps. While no framework can completely prevent you from spilling secrets, we think colocating server and client code makes it much more likely.

Allowing server functions to be declared in arbitrary locations also masks the fact that they are effectively creating a publicly accessible endpoint. Even in systems that prevent server functions from being declared in client code (such as "use server" in React Server Components), experienced developers can be caught out. We prefer a design that emphasises the public nature of remote functions rather than the fact that they run on the server, and avoids any confusion around lexical scope.

Design

Before we jump in we want to make clear that this does not affect load functions, they continue to work as is.

Remote functions are declared inside a .remote.ts file. You can import them inside Svelte components and call them like regular async functions. On the server you import them directly; on the client, the module is transformed into a collection of functions that request data from the server.

Today we’re introducing four types of remote function: query, form, command and prerender.

query

Queries are for reading dynamic data from the server. They can have zero or one arguments. If they have an argument, you're encouraged to validate the input via a schema which you can create with libraries like Zod (more details in the upcoming Validation section). The argument is serialized with devalue, which handles types like Date and Map in addition to JSON, and takes the transport hook into account.

import z from 'zod';
import { query } from '$app/server';
import * as db from '$lib/server/db';

export const getLikes = query(z.string(), async (id) => {
  const [row] = await db.sql`select likes from item where id = ${id}`;
  return row.likes;
});

When called during server-rendering, the result is serialized into the HTML payload so that the data isn't requested again during hydration.

<script>
  import { getLikes } from './data.remote';
  
  let { item } = $props();
</script>

<p>likes: {await getLikes(item.id)}</p>

Async SSR isn’t yet implemented in Svelte, which means this will only load in the client for now. Once SSR is supported, this will be able to hydrate correctly, not refetching data

Queries are thenable, meaning they can be awaited. But they're not just promises, they also provide properties like loading and current (which contains the most recent value, but is initially undefined) and methods like override(...) (see the section on optimistic UI, below) and refresh(), which fetches new data from the server. We’ll see an example of that in a moment.

Query objects are cached in memory for as long as they are actively used, using the serialized arguments as a key — in other words myQuery(id) === myQuery(id). Refreshing or overriding a query will update every occurrence of it on the page. We use Svelte's reactivity system to intelligently clear the cache to avoid memory leaks.

form

Forms are the preferred way to write data to the server:

import z from 'zod';
import { query, form } from '$app/server';
import * as db from '$lib/server/db';

export const getLikes = query(z.string(), async (id) => {/*...*/});

export const addLike = form(async (data: FormData) => {
  const id = data.get('id') as string;

  await sql`
    update item
    set likes = likes + 1
    where id = ${id}
  `;

  // we can return arbitrary data from a form function
  return { success: true };
});

A form object such as addLike has enumerable properties — method, action and onsubmit — that can be spread onto a <form> element. This allows the form to work without JavaScript (i.e. it submits data and reloads the page), but it will also automatically progressively enhance the form, submitting data without reloading the entire page.

<script>
  import { getLikes, addLike } from './data.remote';
  
  let { item } = $props();
</script>

<form {...addLike}>
  <input type="hidden" name="id" value={item.id} />
  <button>add like</button>
</form>

<p>likes: {await getLikes(item.id)}</p>

By default, all queries used on the page (along with any load functions) are automatically refreshed following a form submission, meaning getLikes(...) will show updated data.

In addition to the enumerable properties, addLike has non-enumerable properties such as result, containing the return value, and enhance which allows us to customize how the form is progressively enhanced. We can use this to indicate that only getLikes(...) should be refreshed and through that also enable single-flight mutations — meaning that the updated data for getLikes(...) is sent back from the server along with the form result. Additionally we provide nicer behaviour in the case that the submission fails (by default, an error page will be shown):

<script>
  import { getLikes, addLike } from './data.remote';
  
  let { item } = $props();
</script>

{#if addLike.result?.success}
  <p>success!</p>
{/if}

<form {...addLike.enhance(async ({ submit }) => {
  try {
    // by passing queries to `.updates(...)` we will prevent a global refresh and the
    // refreshed data is sent together with the submission response (single flight mutation)
    await submit().updates(getLikes(item.id));
  } catch (error) {
    // instead of showing an error page,
    // present a demure notification
    showToast(error.message);
  }
}}>
  <input type="hidden" name="id" value={item.id} />
  <button>add like</button>
</form>

<p>likes: {await getLikes(item.id)}</p>

form.result need not indicate success — it can also contain validation errors along with any data that should repopulate the form on page reload, much as happens today with form actions.

Alternatively we can also enable single-flight mutations by adding the refresh call to the server, which means all calls to addLike will leverage single-flight mutations compared to only those who use submit.updates(...):

import { query, form } from '$app/server';
import * as db from '$lib/server/db';

export const getLikes = query(async (id: string) => {
  const [row] = await sql`select likes from item where id = ${id}`;
  return row.likes;
});

export const addLike = form(async (data: FormData) => {
  const id = data.get('id') as string;

  await sql`
    update item
    set likes = likes + 1
    where id = ${id}
  `;
  
+ await getLikes(id).refresh();

  // we can return arbitrary data from a form function
  return { success: true };
});

command

For cases where serving no-JS users is impractical or undesirable, command offers an alternative way to write data to the server.

import z from 'zod';
-import { query, form } from '$app/server';
+import { query, command } from '$app/server';
import * as db from '$lib/server/db';

export const getLikes = query(z.string(), async (id) => {
  const [row] = await sql`select likes from item where id = ${id}`;
  return row.likes;
});

-export const addLike = form(async (data: FormData) => {
-  const id = data.get('id') as string;
+export const addLike = command(z.string(), async (id) => {

  await sql`
    update item
    set likes = likes + 1
    where id = ${id}
  `;
  
  getLikes(id).refresh();

  // we can return arbitrary data from a command
  return { success: true };
});

This time, simply call addLike, from (for example) an event handler:

<script>
  import { getLikes, addLike } from './data.remote';
  
  let { item } = $props();
</script>

<button
  onclick={async () => {
    try {
      await addLike();
    } catch (error) {
      showToast(error.message);
    }
  }}
>
  add like
</button>

<p>likes: {await getLikes(item.id)}</p>

Commands cannot be called during render.

As with forms, we can refresh associated queries on the server during the command or via .updates(...) on the client for a single-flight mutation, otherwise all queries will automatically be refreshed.

prerender

This function is like query except that it will be invoked at build time to prerender the result. Use this for data that changes at most once per redeployment.

import z from 'zod';
import { prerender } from '$app/server';

export const getBlogPost = prerender(z.string(), (slug) => {
  // ...
});

You can use prerender functions on pages that are otherwise dynamic, allowing for partial prerendering of your data. This results in very fast navigation, since prerendered data can live on a CDN along with your other static assets.

When the entire page has export const prerender = true, you cannot use queries, as they are dynamic.

Prerendering is automatic, driven by SvelteKit's crawler, but you can also provide an entries option to control what gets prerendered, in case some pages cannot be reached by the crawler:

import z from 'zod';
import { prerender } from '$app/server';

export const getBlogPost = prerender(
  z.string(),
  (slug) => {
    // ...
  },
  {
    entries: () => ['first-post', 'second-post', 'third-post']
  }
);

If the function is called at runtime with arguments that were not prerendered it will error by default, as the code will not have been included in the server bundle. You can set dynamic: true to change this behaviour:

import z from 'zod';
import { prerender } from '$app/server';

export const getBlogPost = prerender(
  z.string(),
  (slug) => {
    // ...
  },
  {
+   dynamic: true,
    entries: () => ['first-post', 'second-post', 'third-post']
  }
);

Optimistic updates

Queries have an withOverride method, which is useful for optimistic updates. It receives a function that transforms the query, and must be passed to submit().updates(...) or myCommand.updates(...):

<script>
  import { getLikes, addLike } from './data.remote';
  
  let { item } = $props();
</script>

<button
  onclick={async () => {
    try {
-      await addLike();
+      await addLike().updates(getLikes(item.id).withOverride((n) => n + 1));
    } catch (error) {
      showToast(error.message);
    }
  }}
>
  add like
</button>

<p>likes: {await getLikes(item.id)}</p>

You can of course do const likes = $derived(getLikes(item.id)) in your <script> and then do likes.withOverride(...) and {await likes} if you prefer, but since getLikes(item.id) returns the same object in both cases, this is optional

Multiple overrides can be applied simultaneously — if you click the button multiple times, the number of likes will increment accordingly. If addLike() fails, the override releases and will decrement it again, otherwise the updated data (sans override) will match the optimistic update.

Validation

Data validation is an important part of remote functions. They look like regular JavaScript functions but they are actually auto-generated public endpoints. For that reason we strongly encourage you to validate the input using a Standard Schema object, which you create for example through Zod:

import { query } from '$app/server';
import { z } from 'zod';

const schema = z.object({
  id: z.string()
});

export const getStuff = query(schema, async ({ id }) => {
    // `id` is typed correctly. if the function
    // was called with bad arguments, it will
    // result in a 400 Bad Request response
});

By default a failed schema validation will result in a generic 400 response with just the text Bad Request. You can adjust the returned shape by implementing the handleValidationError hook in hooks.server.js. The returned shape must adhere to the shape of App.Error.

// src/hooks.server.ts
import z from 'zod';

export function handleValidationError({ result }) {
  return { validationErrors: z.treeifyError(result.error)}
}

If you wish to opt out of validation (for example because you validate through other means, or just know this isn't a problem), you can do so by passing 'unchecked' as the first argument instead:

import { query } from '$app/server';

export const getStuff = query('unchecked', async ({ id }: { id: string }) => {
    // the shape might not actually be what TypeScript thinks since bad actors might call this function with other arguments
});

In case your query does not accept arguments you don't need to pass a schema or 'unchecked' - validation is added under the hood on your behalf to check that no arguments are passed to this function:

import { query } from '$app/server';

export const getStuff = query(() => {
    // ...
});

The same applies to prerender and command. form does not accept a schema since you are always passed a FormData object which you need to parse and validate yourself.

Accessing the current request event

SvelteKit exposes a function called getRequestEvent which allows you to get details of the current request inside hooks, load, actions, server endpoints, and the functions they call.

This function can now also be used in query, form and command, allowing us to do things like reading and writing cookies:

import { getRequestEvent, query } from '$app/server';
import { findUser } from '$lib/server/db';

export const getProfile = query(async () => {
  const user = await getUser();
  
  return {
    name: user.name,
    avatar: user.avatar
  };
});

// this function could be called from multiple places
function getUser() {
  const { cookies, locals } = getRequestEvent();
  
  locals.userPromise ??= findUser(cookies.get('session_id'));
  return await locals.userPromise;
}

Note that some properties of RequestEvent are different in remote functions. There are no params or route.id, and you cannot set headers (other than writing cookies, and then only inside form and command functions), and url.pathname is always / (since the path that’s actually being requested by the client is purely an implementation detail).

Redirects

Inside query, form and prerender functions it is possible to use the redirect(...) function. It is not possible inside command functions, as you should avoid redirecting here. (If you absolutely have to, you can return a { redirect: location } object and deal with it in the client.)

Future work / open questions

Server caching

We want to provide some kind of caching mechanism down the line, which would give you the speed of prerendering data while also reacting to changes dynamically. If you're using Vercel, think of it as ISR on a function level.

We would love to hear your opinions on this matter and gather feedback around the other functions before committing to a solution.

Client caching

Right now a query is cached and deduplicated as long as there's one active subscription to it. Maybe you want to keep things around in memory a little longer, for example to make back/forward navigation instantaneous? We haven't explored this yet (but have some ideas) and would love to hear your use cases (or lack thereof) around this.

Prerendered data could be kept in memory as long as the page is open — since we know it’s unchanging, it never needs to be refetched. The downside is that the memory could then never be freed up. Perhaps this needs to be configurable.

Conversely, for queries that we know will become stale after a certain period of time, it would be useful if the query function could communicate to the client that it should be refetched after n seconds.

Batching

We intend to add client-side batching (so that data from multiple queries is fetched in a single HTTP request) and server-side batching that solves the n + 1 problem, though this is not yet implemented.

Streaming

For real-time applications, we have a sketch of a primitive for streaming data from the server. We’d love to hear your use cases.

[elliott-with-the-longest-name-on-github]

yet another long-awaited feature

[Ayushkumar48]

but It will definitely make SvelteKit a great framework like a Swiss knife of the frameworks.

[saturnonearth]

The hype is real for this - amazing changes - and validation!!! Omg..

For real-time applications, we have a sketch of a primitive for streaming data from the server. We’d love to hear your use cases.

*cough* Zero *cough* 👀

[Rich-Harris]

I assume it refers to https://zero.rocicorp.dev...

[saturnonearth]

I assume it refers to https://zero.rocicorp.dev...

Ha yes!! Probably should have been more clear. I am just a strong advocate for sync/local-first and would love Svelte to lead the charge.

Loving the future for Svelte and SvelteKit

[JonathonRP]

Possibly also convex 😉

[samal-rasmussen]

All these real time frameworks are way overbuilt. All we need is a primitive like the command fn that subscribes to data over a websocket and returns a signal/observable/store, and we can build our own solutions on top of that.

[Rich-Harris]

This should give you an idea where our head's at: #12973 (comment)

[abdelfattahradwan]

I am about to cry 🥹 This is a freaking great feature!.

[chanmathew]

Brilliant 🎉

[ottomated]

I'm excited to see the idea for validation! Have you considered something like this to avoid the extra import and slightly awkward nested functions?

export const getStuff = query.validate(schema, async ({ id }) => {
  // `id` is typed correctly. if the function
  // was called with bad arguments, it will
  // result in a 422 response
});

[Rich-Harris]

Yes, considered and rejected — it's more surface area (you need command.validate, form.validate, prerender.validate and so on) and less composable (you might want to use validation with a function that's called by a query, rather than the query itself). Much better to use composition

[ottomated]

Makes sense! My only counter-argument would be that validation should be the default case 99.9% of the time, and it doesn't feel like that with the composed approach. I don't know if it exists, but I would love to see a clean solution that pushes users towards validating all their functions (I hope we agree that all server functions being validated is the ideal!)

[Rich-Harris]

I'm going to copy and paste what I wrote during an internal discussion on this topic:

In the case of a query, which has no side-effects (unless you are actively choosing to shoot yourself in the foot), malformed input will just return something useless — there's no way to use this for mischief:

export const find_nearest_city = query((lat: number, lng: number) => {
  let min_distance = Infinity;
  let closest = null;

  for (const city of cities) {
    const distance = get_distance(city, { lat, lng });
    if (distance < min_distance) {
      min_distance = distance;
      closest = city;
    }
  }

  return city;
});

---

Even with commands, sometimes there are no arguments — there's nothing to validate here, so if command expected a schema it would just be annoying boilerplate:

export const hit_counter = command(() => {
  await db.increment('hits');
});

---

And even when there are arguments, the value of validation is overstated. In a case like this, I only need to check that the user is authenticated (which Standard Schema obviously can't help me with). Validating that id is a number doesn't really give me any additional protection, because the requester can only interact with their own posts, and because if they passed something other than a number the most likely outcome is that db.get_post(id) would just fail.

// we need validation here, but of the user, not the arguments,
// and the logic really needs to go inside the function itself
export async function delete_post(id: number) {
  const { locals } = getRequestEvent();

  if (!locals.user) error(401);

  const post = await db.get_post(id);
  if (post.author !== locals.user.id) error(403);

  await db.delete_post(id);
}

---

Validation doesn't magically make things secure. It's a valid user ID? Cool. Whose?

So I don't think we should require validation, we should just encourage it by offering a validate function that uses Standard Schema:

import { validate } from '@sveltejs/kit';
import * as v from 'valibot';

const schema = v.tuple([
  v.pipe(v.number(), v.minValue(-180), v.maxValue(180)),
  v.pipe(v.number(), v.minValue(-180), v.maxValue(180))
]);

export const find_nearest_city = query(
  validate(schema, ([lat, lng]) => {
    // ...
  })
);

Given that a validation error could occur because of someone probing remote function endpoints, the appropriate response here is a 400 with a generic 'Bad Request' message, rather than detailed instructions on how to pass validation. More granular checks like 'this email address is already in use' should be handled manually by the developer and result in 422s.

[ottomated]

Here's an example of a vulnerability that could arise:

export const delete_post = command((id: number) => {
  const post = await posts.findOne({
    id
  });
  if (!user_can_delete(post)) error(403);
  await posts.delete({
    id
  });
});

Looks fine, right? What if a malicious user sends the following:

await delete_post({ lte: 20 });

The findOne could return post 20 and pass the check, and then delete all posts from 0-20.

[jose-manuel-silva]

@Rich-Harris I get the reasoning about validation not being a magic security bullet, and the composability stuff makes sense.

But @ottomated's injection example shows how dangerous the "malformed input just returns useless data" assumption can be. The TypeScript signature says id: number but that's meaningless at runtime - malicious clients can send whatever JSON they want.

Looking at how other libraries do this, the nested approach feels weird:

tRPC does:

.input(schema)
.mutation(({ input }) => { ... })

next-safe-action does:

action(schema, (input) => { ... })

Everyone else puts validation first, handler second. SvelteKit's approach of burying the handler inside the validation function is pretty unique.

I get your composability point about validating sub-functions, but you could still achieve that with a validation-first API:

// Common case: validation prominent  
export const deleteUser = command(
  z.object({ id: z.string() }),  
  async ({ id }) => {
    // id is typed correctly, 400 on bad input
  }
);

// Your composability case: validate a sub-function
const validateInput = z.object({ id: z.string() }).parse;

export const complexThing = command(
  validateInput,  // any transformation function works
  async (validated) => { 
    // can call other functions with validateInput
  }
);

// Edge case: explicit opt-out
export const hitCounter = command.raw(() => {
  await db.increment('hits');
});

This keeps your composability while making validation visually prominent for the dangerous cases. The current nested approach makes it too easy to skip validation.

What do you think?

[itsmikesharescode]

wow!

[geodask]

Wow, this is awesome! It seems so intuitive and satisfying to use!

[ollema]

sounds great!

I have been struggling to implement a fairly complex SvelteKit-app that renders sequences of sensor data from lidars, cameras and radars.

each frame in a sequence can be 20-100 mb. at the same time, the sensor data is pretty static so caching can and will be used on as many levels as possible.

super interested in what you have planned for caching!

Server caching

We want to provide some kind of caching mechanism down the line, which would give you the speed of prerendering data while also reacting to changes dynamically.

this would be great and it would basically replace what I have implemented on my own to cache requests. it would be great with control over at least max size when used as some LRU-cache. but also max size in terms of size on the disk and maybe also some TTL. and of course some way to manually invalidate the cache per function or globally, if needed.

Client caching

Right now a query is cached and deduplicated as long as there's one active subscription to it. Maybe you want to keep things around in memory a little longer, for example to make back/forward navigation instantaneous? We haven't explored this yet (but have some ideas) and would love to hear your use cases (or lack thereof) around this.

Prerendered data could be kept in memory as long as the page is open — since we know it’s unchanging, it never needs to be refetched. The downside is that the memory could then never be freed up. Perhaps this needs to be configurable.

yeah this would also be useful! I would even go one step further and consider some sort of persistent cache for users - maybe in IndexedDB or something along those lines?

otherwise that is something I plan to implement anyways - so I don’t have to stream hundreds of megabytes to a user if they accidentally refresh the page. again one thing less I would have to implement in userland so if this was provided as some opt-in feature by sveltekit it would be the dream.

the same level of configuration I brought up for the server caching would be useful in a persistent client side cache as well

—-

please let me know if I can provide feedback in any more structured way, I would love to test this out in practice later on and help out as much as I can

[darrylyeo]

A built-in client-side cache would be amazing. Would allow me to completely remove TanStack Query as a dependency.

[ziedHamdi]

This reminds me of the days I was a GWT expert, back in 2010-16. I must say there were disappointments with the RPC calls architecture, but I forgot the use cases. What I remember is that it was frustrating to call them manually, eg. from a mobile app, so I had to isolate then as only callers to service methods (having them like boilerplate code). Maybe the architecture would allow a non proprietary protocol so that it can be implemented in case of need...

[wiesson]

Where can I subscribe so that I get a notification once this is testable? The form part is incredibly valuable <3

[dummdidumm]

PR will hopefully go up later this week, we'll update the discussion with a link to it and example then.

[Defman]

Any updates =)

[rebasecase]

#13957

[rossrobino]

This is going to be incredible, this and async address all of the features I have been wanting from Svelte.

One question for the team, have you considered adding a Form component property instead of spreading? I feel like could be a bit more readable, especially with enhance.

<script>
  import { getLikes, addLike } from './data.remote';
  
  let { item } = $props();
</script>

<addLike.Form enhance={async () => {...}}>
  <input type="hidden" name="id" value={item.id} />
  <button>add like</button>
</addLike.Form>

<p>likes: {await getLikes(item.id)}</p>

[Rich-Harris]

Aesthetically I'd prefer <addLike.form ...> (and <addLike.button> for <button formAction="...">), but yes, this is worth considering.

The main reason not to do it is that you can no longer use element-specific directives like transitions — our goal is to replace those with more flexible programmatic APIs that can be used with attachments, but for now attachments only replace actions, and there's still stuff like bind:clientWidth which works on elements but not components.

[theetrain]

I'm not sure if <addLike.Form> (or <addLike.form>) resemble any existing markup pattern; I believe custom elements can only be dash-separated like <addlike-form>; and Svelte components must be capitalized like <AddLike.Form>. Even when explained, it's challenging for me to mentally map <addLike.Form> to an eventually-rendered <form>.

How about this twist:

<script>
  import { getLikes, addLike } from './data.remote';

+ import { Form } = addLike
  
  let { item } = $props();
</script>

+<Form enhance={async () => {...}}>
  <input type="hidden" name="id" value={item.id} />
  <button>add like</button>
+</Form>

<p>likes: {await getLikes(item.id)}</p>

Though I'm unsure if we can compiler away the theoretical Form component property on addLike when unused.

I still prefer the markup as proposed, with <form {...addLike}> and <form {...addLike.enhance(() => {})}> since it fits neatly in the world of Svelte and HTML. There's also the concern of styling <Form> since there's no way currently to pass scoped styles down to components.

[Rich-Harris]

Svelte components must be capitalized

nope, they must be capitalized or use dot notation

[huseeiin]

if await getLikes(item.id) is like react/solid <Suspense> how do we have a fallback?

[Rich-Harris]

with <svelte:boundary> sveltejs/svelte#15845

[samal-rasmussen]

EDIT: Ignore this. I didn't see it was a template string.

db.sqlselect likes from item where id = ${id}

Please use prepared statements in your sql examples 😭

[Rich-Harris]

Why?

[samal-rasmussen]

Because teaching newbies to trust that a function that accepts and runs an sql query against a db will be doing proper sanitizing for them, will let them down.

[elliott-with-the-longest-name-on-github]

not really, this is just how modern sql libraries do parameterization: https://orm.drizzle.team/docs/sql#sql-template, https://www.npmjs.com/package/@vercel/postgres, https://www.npmjs.com/package/postgres

[JabSYsEmb]

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals

[samal-rasmussen]

Lord I didn't even spot it was a template literal. Sorry about that. That is very different from a function call. Modern js is magical.

(Sometimes I wonder how I manage to be a professional developer even when I am often character blind like this.)

[kran6a]

While I don't think I will use this many times since I build mostly true SPAs with a separate backend, I really believe these will be very useful for fullstack apps or backend-for-frontend apps.

There are two additions I would add:

Output validation

Not so much due to the validation but due to the validator being able to transform the output (setting default values for null/undefined fields, removing extra keys, etc.).

I think a tRPC-like signature like this would be more ergonomic if output validation is added but the signature is definitely not a big deal:

const my_procedure = rpc
    .input(input_schema)
    .output(output_schema)
    .query(schema, async (input) => {
        //body
      })
    //maybe allow chaining a .mutation here to create a mutation that implicitly invalidates the query?

Support for middleware (using the tRPC-like signature above)

Middlewares are a great way to manage dependency injection in a declarative manner.

const my_procedure = rpc
    .input(input_schema)
    .output(output_schema)
    .middleware(services) //Whatever is returned from a middleware is passed to the next middleware as the first parameter
    .middleware(logging)
    .middleware(stats)
    .middleware(with_cache({storage: 'redis', ttl: 3600})) //The function returned by with_cache() would be accessing a redis service returned by the first middleware
    .query(schema, async (input, ctx) => { //ctx holds the awaited return value of the last middleware
        //body
      })

I also would like to know what are the plans regarding load functions.
Is this considered a replacement that will eventually lead to load functions being marked as deprecated?

Personally I think load functions fill a different role, specially on SPAs, where they can be used as a mechanism for dependency/service injection and state management. I even consider them a better context alternative.
When I started building SPAs with svelte-kit I overlooked them because they were way more limited as they couldn't use browser APIs and did not support returning $state-ful values, but now I think they are the best cross-component state and dependency management solutions out there for SPAs: state and services stay scoped to the page/layout where they are defined (you can even create +layout.ts files without their corresponding +layout.svelte file just for state/dependency management purposes!), automatic and intuitive composition due to their monadic nature, automatic invalidation, type-safety, automatic injection via the data prop, ability to preload state and initialize services needed by the page you will visit next... The only thing I miss is not being able to define teardown logic in load functions to deinit services, but it is a minor inconvenience given the DX they provide.

[elliott-with-the-longest-name-on-github]

output validation

Why would this ever be needed / isn't this what TypeScript is for? You're already in control of the data you return from the function, so just... don't return data in the wrong shape / type the result of your function. (Am I missing something?)

middleware

Is this necessary in a world where you have access to getRequestEvent? Wouldn't you put your services on locals and access them there?

[Rich-Harris]

@elliott-with-the-longest-name-on-github i assume you meant this to be a reply to the previous thread

[kran6a]

Why would this ever be needed / isn't this what TypeScript is for? You're already in control of the data you return from the function, so just... don't return data in the wrong shape / type the result of your function. (Am I missing something?)

This requires using a return type annotation on the handler function. Otherwise, a query like "SELECT * FROM table" or the ORM equivalent would return new fields should you update your DB schema without breaking anything in typescript.

Having to annotate return types increase maintenance/refactoring time, as they are not automatically updated when you update your typed SQL/ORM queries and depending on the typescript config you are using, it may not report additional properties being present as an error. Also I bet the return type annotation will make the compiler lie to the frontend about the true returned data type, which may lead to sensitive fields traveling through the network unnoticed. Reporting additional properties as an error might be something you don't want to turn on (at least I don't do it even if I inherit from @tsconfig/strictest).

There is also the case where you get weird return types from third party libs like

type User = {
    followers: User[] | null //This is null when the user has no followers. Replacing null by an array simplifies dealing with the field
    created_at: Date, //We want to stringify Dates
    last_active: Date | null //This is null if the user never logged in because our DB guy needed it for stats (users that registered but never logged in). Replacing null by the created_at field would be a sensible choice
}

You can actually do something like

return {
    ...user,
    followers: user.followers ?? [] satisfies User["followers"],
    last_active: user.last_active?.toString() ?? user.created_at.toString()
}

Or even wrap that logic in a function taking an User, but I find having a user_schema definition that does this same thing using zod way more readable and composable, specially if there are several endpoints that return objects of the User type coming from the same third party library/service/ORM.

Is this necessary in a world where you have access to getRequestEvent? Wouldn't you put your services on locals and access them there?

This will depend on the complexity of your backend. For low to medium complexity backends it would be enough, but as your backend starts needing to scale you will start encountering things that cannot be done properly or safely by defining a global and static set of services:

You may want to provide different service implementations (or service configurations) to different endpoints (redis cache VS in-memory cache, a per-endpoint set of rabbitmq queues or event buses with typed names and schemas, etc). Otherwise you will end with all rabbitmq queues, caches and event buses available to all endpoints, which results in a cluttered intellisense autocomplete and options that will certainly cause bugs being listed as available (ie: an immutable edge cache appearing as an option on an endpoint that returns variable data, events being emitted on the wrong event bus, etc.).

[Rich-Harris]

Both of these problems are better solved with normal functions

[rebasecase]

Whenever your function's output may depend on untrusted or dynamic inputs whose validity your type annotations cannot actually enforce at runtime.

[aster-void]

We must think of naming convention for this, it's very confusing otherwise:

<!--
is `getLikes` a normal async function or a remote query?
if this is normal function, it should be deduped to reduce network traffic.
-->
<span>
{await getLikes(post.id)} likes
</span>

<!-- somewhere else ... -->
<LikeButton
  count={await getLikes(post.id}
  onclick={async () => {
    // is `like` just an async function or a remote command?
    // if it's a command, it should update the getLikes with `updates` for one-round trip update.
    await like(post.id);
    await getLikes(id).refresh();
  }}
/>

[aster-void]

I'm thinking of something like

xxxQuery for queries
xxxCommand for commands

because

• it's very clear that these are queries and commands
• it's auto-completion friendly
• although slightly verbose

[dummdidumm]

You are free to impose naming conventions on your projects but we will not force anything like that

[ESchouten]

Would remote functions SSR work with workbox-strategies?
This service worker native way of caching and syncing data being incompatible with the load function SSR is a big part of having to opt out of SSR for applications that should remain working offline.

[Rich-Harris]

Can you elaborate on what that entails exactly? If it means something like 'populating a cache with server-rendered data' then no, I don't think it would be, but I would like to explore turnkey strategies for this stuff that are better integrated with the framework.

Things like workbox involve you duplicating your routes in your service worker, which is convoluted and brittle (no shade, that's just what's required of an unopinionated solution) — to my eyes it would be better if you defined things like 'this query can be cache-first, this one should be network-first, this one is network-only' in the query. SvelteKit can populate caches on startup with server-rendered data, while respecting your strategy and cache duration preferences (prerender data can be cached immutably, of course, as long as the cache key includes the deployment version).

Note that since we control the requests, we don't even need a service worker for this to work — we can just inspect window.caches directly (though it would work fine with your service worker if you were using one to e.g. make pages available offline).

[ESchouten]

Indeed, workbox is just the tool I am currently using to fulfill the need of data availability when offline without having to manually initialize, store and sync state.

With the self-managed remote functions it indeed seems more logical to me to manage the caching strategy through SvelteKit e.g. with window.cache since it enables a more flexible use of the cache, e.g. allowing old data in one part of the site and disallowing in another).

I guess the reason for my comment above is, what I am really missing is a way of request/response (JSON) data caching where I don't have to worry about managing this cache/state myself.
At this moment in lack of a better solution, workbox-strategies does that for me, though with the downsides of not working with load function SSR and requiring explicit REST endpoints, untyped via +server.ts files.

[sillvva]

Will you be able to call the remote functions from the <script module> block of a page?

[Rich-Harris]

You can call them from wherever your heart desires

[wiesson]

I can't add feedback to the PR, but I'd like to mentioned that I wanted to give the remote functions branch a try, but it looks like the __SVELTEKIT_CLIENT_ROUTING__ has been removed (by accident?)

https://github.com/sveltejs/kit/pull/13986/files#diff-beef34c36ed87d7835d0166655010910fba9949a6ef95042cb468d7d73423816L337

Results in this error on load

Uncaught (in promise) ReferenceError: SVELTEKIT_CLIENT_ROUTING is not defined.

I assume, I just need to be patient :)

[dummdidumm]

yes remove by accident, fixed now

[saruman-tech]

export const get = query(z.string(), async (str) => {
	console.log(str);
	return 'ok';
});

Hello, I found a bug. When calling this get remote function, if the string passed in is in Chinese, an error will be reported.

DOMException [InvalidCharacterError]: Invalid character

    at btoa (node:buffer:1289:11)

    at stringify_remote_arg (/usr/src/app/node_modules/.pnpm/@sveltejs+kit@https+++pkg.pr.new+sveltejs+kit+@sveltejs+kit@13986_@sveltejs+vite-plugin_38d5c03b2a7dc74b11d467cf931a6d6c/node_modules/@sveltejs/kit/src/runtime/shared.js:44:9)

    at get_response (/usr/src/app/node_modules/.pnpm/@sveltejs+kit@https+++pkg.pr.new+sveltejs+kit+@sveltejs+kit@13986_@sveltejs+vite-plugin_38d5c03b2a7dc74b11d467cf931a6d6c/node_modules/@sveltejs/kit/src/runtime/app/server/remote.js:824:48)

    at /usr/src/app/node_modules/.pnpm/@sveltejs+kit@https+++pkg.pr.new+sveltejs+kit+@sveltejs+kit@13986_@sveltejs+vite-plugin_38d5c03b2a7dc74b11d467cf931a6d6c/node_modules/@sveltejs/kit/src/runtime/app/server/remote.js:116:25

    at wrapper (/usr/src/app/node_modules/.pnpm/@sveltejs+kit@https+++pkg.pr.new+sveltejs+kit+@sveltejs+kit@13986_@sveltejs+vite-plugin_38d5c03b2a7dc74b11d467cf931a6d6c/node_modules/@sveltejs/kit/src/runtime/app/server/remote.js:123:3)

    at load (/usr/src/app/src/routes/(public)/+page.ts:14:21)

    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)

    at async load_data (/usr/src/app/node_modules/.pnpm/@sveltejs+kit@https+++pkg.pr.new+sveltejs+kit+@sveltejs+kit@13986_@sveltejs+vite-plugin_38d5c03b2a7dc74b11d467cf931a6d6c/node_modules/@sveltejs/kit/src/runtime/server/page/load_data.js:208:17)

    at async eval (/usr/src/app/node_modules/.pnpm/@sveltejs+kit@https+++pkg.pr.new+sveltejs+kit+@sveltejs+kit@13986_@sveltejs+vite-plugin_38d5c03b2a7dc74b11d467cf931a6d6c/node_modules/@sveltejs/kit/src/runtime/server/page/index.js:190:13)

[ottomated]

Can command include the most recent error, similar to form?

<script>
  import { update } from './items.remote';
</script>

<button onclick={async () => {
  await update(data);
}}>Update</button>

{#if update.error}
  <div>Error: {update.error}</div>
{/if}

[ottomated]

I'd also like to see RemoteCommand exported to mirror RemoteQuery and RemoteFormAction

[ottomated]

It's a bit unintuitive that RemoteQuery has to be used like this:

<script lang="ts">
  const { query }: {
    query: RemoteQuery<void, Promise<string>>
  } = $props();
</script>

as opposed to just RemoteQuery<void, string>. Having to specify the promise is confusing because it doesn't have any effect on the use of the function.

[LukeHagar]

I’m in agreement here, the promise can just be baked into the type, since they are all remote they will always be promises except for maybe the pre-rendered one

[aster-void]

Also we don't see promises when we only use .current

[ottomated]

Has there been any thought about an opinionated way to implement paginated queries? I've been thinking about what it would look like in userland, and it could get pretty complicated — you'd have to maintain a list of all the fetched pages because there's no way to access sveltekit's internal query cache directly.

[jycouet]

You will need to pass in loadMore the cursor and it should be good ?
It's not that easy to get it right, but once you have the good 20lines it's great 🤌

For cursor to work well you will need to pass orderby and filters also. (I mean, that's why I think it's kinda custom)

Svelte primitives looks promising already 😉

[ottomated]

You will need to pass in loadMore the cursor and it should be good ?

I don't understand the question. In my example, loadMore would automatically use the last page's cursor. If you mean to argue that it can be implemented in userland:
Imagine you have 2 pages

• cursor: null, page: [20, 19, 18], nextCursor: 17
• cursor: 17, page: [17, 16, 15], nextCursor: 14

If you invalidate the 2nd page, all works perfectly. However, say you invalidate the first page and it returns

• page: [21, 20, 19], nextCursor: 18

Now you need to also refresh page 2, but with a new input, which is impossible afaik with plain queries.

[jycouet]

oOups, sorry, I guess I didn't understand you.
You are proposing a new api, infiniteQuery, right ? Or it's something that exist already and I miss it ?

How do you invalidate the 2nd page ? invalidate the first page and it returns ... ?
It's part of your proposal ? Or link with .refresh() ?

[catinrage]

Would and API like this be any helpful :

export const load = query(function* () {
  let offset = 0;
  const limit = 10;

  while (offset < comments.length) {
    yield loadComments(offset, limit);
    offset += limit;
  }
});

Honestly, I’m not sure if query can accept generator functions, just experimenting here, taking a shot in the dark.

[ottomated]

I thought about a generator function, but no – it would need to be resumable in a new http request and therefore serialize the state of all the local variables. I don't think there's a realistic way of doing that.

[nevthereal]

what does the submit() in the form enhance do?

[nevthereal]

okay I see, thanks. so it kinda allows me to tap into the form submission process before I actually submit.

I want to send additional data to the form, specifically the task ID I want to change the due date of. how would I send this additional data with the form?

[Rich-Harris]

use a hidden <input>

[nevthereal]

I see, that's also how I did it in the past. My question is could it be possible to tap into the submit function and add the additional data there? Because I'd see a lot of benefits there since I think hidden <inputs> could be a bit sketchy (correct me if I am wrong please). I just don't really find this solution particularly elegant

[Rich-Harris]

They're not 'sketchy', this is what hidden inputs are for. If you go rogue and mutate the form data before submitting it, all you're doing is making your app less reliable (e.g. submissions won't work if they happen while the user has briefly lost connectivity)

[nevthereal]

thanks! and thanks for your time. really good work you put in there

[saruman-tech]

Hello, I have a problem when making paginated data

const searchParams = $derived(new SvelteURLSearchParams(page.url.search));
const currentPage = $derived(Number(searchParams.get('page')) || 1);
const currentSearch = $derived(searchParams.get('search') || '');
const currentCategory = $derived(searchParams.get('category') || '');
let data = $derived(
  remoteData({
    page: currentPage,
    search: encodeURIComponent(String(currentSearch)),
    category: encodeURIComponent(String(currentCategory))
  })
);

If await remoteData changes the query parameters while getting data, it will cause

await_reactivity_lossDetected reactivity loss when reading `Resource.#raw`. This happens when state is read in an async function after an earlier `await`

If the following changes can solve the problem of await_reactivity_lossDetected, but the remote function still returns an error with http status 200, I cannot reasonably judge whether the returned data is valid or an error. Have I done something wrong? Is there a reasonable solution?

const searchParams = new SvelteURLSearchParams(page.url.search);
const currentPage = Number(searchParams.get('page')) || 1;
const currentSearch = searchParams.get('search') || '';
const currentCategory = searchParams.get('category') || '';
let data = $state(
  await remoteData({
    page: currentPage,
    search: encodeURIComponent(String(currentSearch)),
    category: encodeURIComponent(String(currentCategory))
  })
);
$effect(() => {
  const searchParams = new SvelteURLSearchParams(page.url.search); 
  const currentPage = Number(searchParams.get('page')) || 1; 
  const currentSearch = searchParams.get('search') || ''; 
  const currentCategory = searchParams.get('category') || ''; 
  remoteData({ 
    page: currentPage, 
    search: encodeURIComponent(String(currentSearch)), 
    category: encodeURIComponent(String(currentCategory)) 
  }).then((v) => (data = v)); 
});

[saruman-tech]

why aren't you using $derived instead of doing state + effect?

const data = $derived.by(async () => {
  const searchParams = new SvelteURLSearchParams(page.url.search); 
  const currentPage = Number(searchParams.get('page')) || 1; 
  const currentSearch = searchParams.get('search') || ''; 
  const currentCategory = searchParams.get('category') || ''; 
  return await remoteData({ 
    page: currentPage, 
    search: encodeURIComponent(String(currentSearch)), 
    category: encodeURIComponent(String(currentCategory)) 
  }); 
});

I tried it and it still appears

[svelte] await_reactivity_lossDetected reactivity loss when reading Resource.#overrides.length. This happens when state is read in an async function after an earlier await

[sina-salahshour]

@saruman-tech i tried with derived and didn't get any errors.
https://github.com/sina-salahshour/svelte-kit-d-13897-13832972

[sina-salahshour]

@Rich-Harris currently $derived.by with async function, returns a promise of the result. wouldn't it be cool to have it awaited? or other workaround instead of iife + $derived?
for example:

$derived.by(async () => 19)

returns

Promise {<fulfilled>: 19}

so we would have to do

$derived(await (async () => 19)())

to have the return data resolved

[saruman-tech]

@saruman-tech i tried with derived and didn't get any errors. https://github.com/sina-salahshour/svelte-kit-d-13897-13832972

Thanks for helping me but I still get warnings in the console when I pull your repository

[svelte] await_reactivity_loss
Detected reactivity loss when reading `Resource.#overrides.length`. This happens when state is read in an async function after an earlier `await`
https://svelte.dev/e/await_reactivity_loss

And an exception occurs when entering the /data route or other pages

Uncaught (in promise) TypeError: Cannot read properties of null (reading 'before')

I think this should also happen to you. I tried Google Chrome and Safari and updated dependencies

[rmunn]

@Rich-Harris currently $derived.by with async function, returns a promise of the result. wouldn't it be cool to have it awaited? or other workaround instead of iife + $derived? for example:

That's already been considered, but it doesn't work: see sveltejs/svelte#15845 (and scroll down to the "No async $derived.by" section) for the details, and pay attention to the warning about needing to pass state in as parameters or you'll experience subtle bugs.

[ottomated]

There needs to be a way to make a form invalidate nothing - currently it's either everything or a specified set of queries. Maybe

<form
  {...addTodo.enhance(({ submit }) => {
    submit().updatesNothing();
  })}
>

[samuba]

Can we get an abort signal into this somehow? Would be sweet to be able to use the new getAbortSignal with this.

[vipero07]

About a year into a sveltekit project and the pageloads + superforms are driving me nuts now. I'm gonna turn on experimental for this ASAP because I spent a few brain cycles thinking "how can I do SSR + CSR inside a svelte component to fix this mess". This is exactly what I needed. Cacheing would be huge. Something like zero but ideally without the overhead of zero.

In the recent promise talk @Rich-Harris mentioned batching, and if you can individually query n and n+1 items and they can all be retrieved at the same time but cached individually such that a request for n and n+2 would get n from the cache and only hit the db for n+2 that would be incredible. This is very much my pie in the sky dream though, I don't expect that kind of thing.

[saturnonearth]

About a year into a sveltekit project and the pageloads + superforms are driving me nuts now.

I don't want to stray too much off-topic here, but - can you expand on this, and how remote-functions will help with superforms/pageloads?

[catinrage]

Superform is useful for simplifying form handling, but in form-heavy pages, creating instances feels like a chore due to all the boilerplate. it doesn’t feel native to Svelte either, especially since it still relies on stores instead of the new svelte 5 runes.

[Rich-Harris]

This is very much my pie in the sky dream though, I don't expect that kind of thing

On the contrary, this is exactly the plan!

[dangodai]

With single flight mutations will it be possible for anyone depending on the refreshed data, possibly even from a different boundary, to know a possible mutation is in progress (i.e. through $effect.pending())? I know we can't know for sure that the data will be refreshed, because the mutation could fail, but we might still want to show some sort of indication that a mutation and possible refresh is in progress.

This is all theoretical (I haven't been able to get SvelteKit working with async Svelte), but I'm imagining a scenario with drag and drop between two components. Either the sender or receiver would initiate the mutation, but not both. Both the sender and the receiver component may want to show some sort of indicator of "saving".

[Rich-Harris]

Good question. We could make .loading true (and .status === 'reloading') when a query is being updated via myCommand().updates(myQuery()) or the form equivalent, perhaps

[dangodai]

That sounds great. Though am I correct that this would only be practical when .updates() is chained on the client, and not when it's called within a mutation on the server? I imagine you might be able to figure out what updates could be called on the server during build time and pass that information to the client, but I'm not sure if the build time analysis could deal with the potential for branching and dynamic arguments.

(If SSEs supported POST we could send information to the client about what is refreshing without defeating the purpose of single flight mutations, but alas I've just learned they are GET only).

Thinking about this problem actually leads me to a possible shortcoming in the API: only the caller of a mutation can apply an override. This could be quite limiting when transferring data between the responses for different queries. To use a real world example, image a Jira clone where you have a Sprint Board component that is responsible for its own data, and a Backlog component responsible for its own data. If you have drag and drop or some other method to move issues between a Sprint Board and Backlog that are both on screen only one of them will call the mutation. Thus only one of them can optimistically update despite the fact that the mutation will affect both of their queries (e.g. getBoard(id) and getBacklog()).

I will have to experiment with a practical implementation to see if I'm reasoning about this correctly though.

Thanks for the great work on this!

[Rich-Harris]

It would only be for client-driven updates, yeah. Trying to statically analyse this is a non-starter, it fails as soon as you encapsulate stuff into shared utilities etc. Having it work in 80% of cases but mysteriously stop working when you stray from the happy path is worth than it not working, but consistently

[dangodai]

Yeah, I had figured that would be the case. It's still useful to have client side, at least. Thanks!

[ottomated]

One thing that seems like a pretty big downgrade for form over legacy actions is type-safe errors. Any app with multiple forms that need to format errors differently means a giant union in App.Error, then you have to keep that up to date - I prefer how form actions infer errors automatically from the return type of fail().

[Rich-Harris]

No, it doesn't — you would still return (not throw) stuff from your form, just as you do with actions today:

export const login = form((data) => {
  const email = data.get('email');
  const password = data.get('password');

  const parsed = Credentials.safeParse({ email, password });

  if (!parsed.success) {
    return {
      type: 'error',
      issues: parsed.error.issues,
      submitted: {
        email
      }
    }
  }

  // optional — could just as easily return nothing
  return {
    type: 'success'
  };
});

You can do whatever discrimination you like. (The fail(status, data) thing is really only about setting the status, which tbh I think would be better achieved with event.setStatus(422).)

[ottomated]

I actually tried that pattern, and it would work if result wasn't a Promise - having to do this everywhere is annoying:

{#if (await form.result)?.issues}
  <!-- my kingdom for postfix .await in javascript... -->
  {#each (await form.result).issues.root as error}
  <!--                       ^ typescript error because it can't infer that issues exists -->
    <p>{error}</p>
  {/each}
{/if}

{#snippet form_error(key: string)}
  <!-- this exported snippet now needs an async boundary, plus currently this doesn't work -->
  {@const error = (await form.result)?.issues?.properties?.[key]}
  {#if error}
    <p class="text-red-500">{error}</p>
  {/if}
{/snippet}

form.currentResult would solve my problem.

[Rich-Harris]

Hmm. form.result shouldn't be a promise, that sounds like a bug, at least in the types

[Rich-Harris]

Okay yeah I'm not seeing this. form.result is just the return value, no promise shenanigans involved