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

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

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

Possibly also convex 😉

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.

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

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

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!)

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.

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.

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

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

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

Any updates =)

#13957

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.

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.

Svelte components must be capitalized

nope, they must be capitalized or use dot notation

with <svelte:boundary> sveltejs/svelte#15845

Why?

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.

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

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

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

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

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

Both of these problems are better solved with normal functions

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

Fair points, the only solution for it would be some kind of opt-in string that gets stripped off like <input name="!email"> but I hate that.

The invalid() proposal seems good to me, I personally don't need to return data in that case.

On the easy-win side, there should totally be a loginForm.inputName function that's just a no-op that checks types (<input name={loginForm.inputName('usernmae')}> would error)

From the frameworks standpoint the guidance could just be, its returning sensitive information for a specific form is concern, use manual issues and clear the data before responding.

Its not ideal to need that caveat, but

1. there is usually 1, maybe 2 forms in an a typical app where that is a concern.
2. for most apps i think people are fine with the compromise of return data that was submitted to them. You would have to explicitly opt in to having a post request cached, so i think the risk of caching accidently is very low.

or just thinking out loud

provider an option to not auto return validation, that again is opt in for a specific remote function.

then my function looks like this.

export const login = form(
  z.object({ email: z.email(), password: z.string().min(8) }),
  async (inputs, invalid, issues) => {
  if(issues.length > 0){
    inputs.password = "";
    return invalid(issues)
  }
  
    if (!await isValid(email, password)) {
      return invalid({
        email: ['Incorrect username or password']
      });
    }

    await actuallyLogin(email, password);
  },
  { continueOnValidationIssue: true }
);

again a little slightly annoying, but most apps only have maybe 1 or 2 of these functions

inputs.password = "";

I don't think this could work because the schema could transform the inputs; the form needs to return the original object

Just chiming in here, as this discussion is highly relevant for us as well. It would be very nice that in the cases where JS is available it would be possible to use the schema on the client to create the errors if no round trip to the server is required.

It could be something like

const loginSchema = z.object({emaiL: z.email(), password: z.string().min(8)})
export const login = form(
  loginSchema,
  async ({ email, password }) => {
    ...
);

<form {...login.enhance(async ({form, data, submit}) => {
          login.validate(loginSchema, data)
          submit();
})}>
  {#if login.issues?.email}<p>{login.issues.email[0]}</p>{/if}
  <input name="email" type="email" />
  
  {#if login.issues?.password}<p>{login.issues.password[0]}</p>{/if}
  <input name="password" type="password" />

  <button>login</button>
</form>

Haven't thought through the naming or api to the end, but being able to populate login.issues and stopping submission using the schema without a roundtrip seems like a very useful usecase.

It may also be an argument for why you should be able to keep some validation out of the schema and in the form function instead, since whether or not its a valid email/password combination is a separate question from whether or not it's actually an email

Isn't SvelteKit now a strictly better version of these tools, language consideration apart? If anything it would let you dispose of them.

Isn't SvelteKit now a strictly better version of these tools, language consideration apart? If anything it would let you dispose of them.

Kind of, yes. But what really sets them apart is that in Svelte, you can’t truly build a fully reactive SSR UI where elements stay completely hidden from the client until they are explicitly delivered by the server. With remote functions, however, you can theoretically achieve this, allowing elements to remain entirely inaccessible to the client and its JavaScript. So I was wondering if there are any significant drawbacks to using remote functions this way. For example, calling them frequently during the same page session to update the UI based on client input.

Not on the Svelte team, but my opinions:

• It's always a good idea to use a form, even it's with JS-driven hidden inputs, because forms handle navigation/state/transitions for you
• But command should arguably support FormData... the only blocker is that devalue isn't async. If devalue had an async option, you could serialize files, crypto keys, Responses, and other objects, so I'm in strong support of async support. (I'm also in strong support of maintaining devalue in other ways but that's not relevant here.)

You can (and probably should) use a form...but then you can just use the command on submit. We can also support the FormData on command and maybe we will, I just don't see a strong use case

I think I ran into something similar when migrating my speech-to-text/transcription endpoint to remote functions.

Initial implementation passed in FormData() but when migrating to command it noted something about non-POJOs so I asked Claude and from one argument it converted into 3 serializable ones - audioData, fileName, mimeType, which still technically worked but when recording anything longer than 10 seconds it errored out with a Maximum call stack exceeded error. Tried a couple different implementations but ran into the same issue every time until I switched back to endpoints.

Good morning!

I always try to use traditional forms whenever possible, but in our case, we have a specific need: parallel uploads of multiple documents or images.

Here's the scenario:

• We have a main form that wraps all the steps in a multistep process. Shared fields are placed as hidden inputs outside the {#if} blocks.
• In one of the steps, users can upload multiple files.
• What we do is: we first submit the main form, and once it succeeds (form.success), we trigger parallel file uploads, showing a modal with the results — whether each upload succeeded or failed — and allowing users to retry if needed.

We follow this approach because:

• Traditional <form> submission doesn't allow parallel uploads.
• We also have strict request size limits, so uploading everything in one go isn't feasible.

Up until now, we’ve used manual uploads with FormData per file, which worked well for us. But I understand this might not align perfectly with the direction of the new remote function architecture.

I also tried using command() for this, but — as others have mentioned — it throws an error because FormData isn't a plain POJO.

So, the solution I came up with was to create a custom POST endpoint that handles parallel file uploads individually.

It might be a niche use case, but I thought I’d share it anyway in case it helps someone else.

Thanks a lot for all the amazing work on Svelte and SvelteKit! I've been using it pretty much since it launched — and honestly, I love it more every day 😄

All the best!

devalue can handle arbitrary types, so in principle we could support async encoders. The way it works for promises returned from load functions (for example) is that the promise becomes a placeholder value, the server goes into streaming mode, and when a promise resolves the server emits a chunk that looks like this:

<script>__sveltekit_xyz123.resolve(${id}, ${value})</script>

No reason in principle we couldn't do something similar going the other way (albeit without the code execution, for obvious reasons). It would inflate the client bundle slightly, of course. Just a matter of devoting attention to it