Actions as functions

[qwuide]

Consider this:

+page.server.js

import { fail, redirect } from '@sveltejs/kit';

export const actions = {
  login: async (event) => {
    const formData = await event.request.formData();

    const email = formData.get('email');
    const password = formData.get('password');

    try {
      await event.locals.auth.login({email, password});
    }
    catch (error) {
      fail(422, {error: error.message});
    };

    redirect(301, '/projects');
  }
};

+page.svelte

<script>
  const { actions } = $props();
</script>
  
<form {...actions.login()}>

  {#if actions.login.data?.error}
    <p>{actions.login.data.error}</p>
  {/if}

  <input type="text" name="email" />
  <input type="password" name="password" />

  <button type="submit" disabled={actions.login.isPending}>
    Login
  </button>
</form>

Actions defined in +page.server.ts will be available on the actions object, which will be passed as a prop to the component.

Each action is a function, which when invoked, returns an object with props that can be spread onto a form element. The interface for such a return value could look something like this:

interface ActionFormProps {
  onsubmit(evt: SubmitEvent): void;
  action: string;
  method: 'POST'
}

The function could also accept an optional options argument, including options as whether the submission should cause a reload and maybe callbacks such as onsuccess and onerror etc.

<form {...actions.login({reload: true})}>
  ...
</form>

Spreading the props onto a form element avoids the need to modify the native <form> element's action attribute (as React does) or require a custom <Form> component (as Qwik does). Instead, we can embrace the form tag as it is, which also aligns nicely with the way routing with plain <a> tags already works in SvelteKit.

And, by using spread props instead of a Svelte use: action, we avoid the need to manually add the action and method attributes to the form to make them available during SSR and enable form submission without JavaScript.

Additionally, the action can be manually invoked by using the perform() method on it. The perform method takes one argument, which could be a plain object or an instance of FormData. It returns a promise that resolves when the action succeeds or throws if the action encounters an error in +page.server.ts.

await actions.login.perform({
  email: '[email protected]',
  password: 'password'
});

Furthermore, the action could expose an isPending property, which becomes true when the action is waiting for the response, and a data property, which is initially null or holds the result of the last invocation of the action. The data property would resemble that of the current form (ActionData) prop, but since it's tailored to the action, it offers the additional advantage of potentially inheriting the types.

So all in all, the interface for this feature might look something like this:

interface ActionOptions {
  reload?: boolean;
  onsuccess?(): Promise<void>;
  onerror?(): Promise<void>;
}

interface ActionFormProps {
  onsubmit(evt: SubmitEvent): void;
  action: string;
  method: 'POST';
}

interface Action<T> {
  (options?: ActionOptions): ActionFormProps;
  perform(data?: FormData | Record<string, unknown>): Promise<void>;
  isPending: boolean;
  data: T | null;
}

This is an idea inspired by server actions in React and route actions in Qwik, which many find very convenient and easy to reason about. However, I don't have enough knowledge to know if it's possible to implement something like this, or if there are other considerations that I haven't thought of. Nonetheless, such a change would require Svelte 5 (due to the ability to send events as props), but I believe it should be possible to implement this without causing any breaking changes. And while this feature isn't essential to get the job done (Svelte and SvelteKit are already awesome as they are!), I think it would simplify and reduce boilerplate code when working with forms and submissions in SvelteKit.

[david-plugge]

I do like your Idea as i experimented a lot with similar patterns. The main issue i have with this is that you need to have the form inside the specific +page.svelte in this scenario. In the end i pretty much always ended up with something similar to trpc.

[qwuide]

Thanks for your reply. Yeah, that limits it quite a bit. Importing these action functions from other +page.server files is not a desirable approach either, I think. String paths have a clear advantage here, and it's likely something that was considered when the current approach was chosen.

In my own code, I have created a createAction(path) function that return an action function with perform(), isPending, etc., based on a path to an action, which could be in another +page.server file. But frankly, it's just a bit of abstraction around a fetch call.