Remote Functions

[dummdidumm]

PR for #13897, discussion should happen there.

For a more complete commit history (with lots of explorations and dead ends; also includes some caching ideas) see #13957

---

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests

• Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

• If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. Changesets that add features should be minor and those that fix bugs should be patch. Please prefix changeset messages with feat:, fix:, or chore:.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 4706f36

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[Rich-Harris]

it's going to take a few passes to fully review this glorious beast, but here's a few notes to start with. also:

• will need a changeset 😆
• if you have a .remote.ts that imports query or whatever from $app/server, then at build time you'll get a 'Cannot import $app/server into client-side code' error rather than the more helpful remote-functions-specific error. Would be nice to be more specific here while not creating a breaking change for anyone that happens to have an existing .remote.ts file (in which case they would probably appreciate a warning that they'll definitely need to rename that file)

Also, I'll probably find the answer to this as I read on but didn't want to lose the thought: are we (de)serializing arguments to remote functions that are called directly on the server? On the one hand it's wasteful, on the other it would avoid a client/server discrepancy (e.g. a mutation being respected on the server but not on the client)

Absolutely pumped for this to land

[Rich-Harris]

Gonna update the behaviour of forms around errors, because it's slightly inconsistent at present. On a form that doesn't use .enhance(...), if a submission errors then the nearest +error.svelte component is rendered. On a form that does use .enhance(...), the nearest +error.svelte page is rendered if JavaScript isn't available, otherwise myForm.error is populated, regardless of whatever error handling logic exists within the enhance callback (which is slightly weird in the case where you try-catch and either handle it or throw a different error).

Aside from the inconsistency, the most likely outcome of this is that errors will just end up getting swallowed, as developers forget to add {#if myForm.error} UI. I'm therefore going to change it so that the nearest +error.svelte is always rendered if there's an unhandled error.

If you try-catch the submit() call, you can (and should, since showing the error page is the second worst outcome behind a silent failure) handle the error however you choose in the progressively enhanced case.

[Rich-Harris]

Am second-guessing the my_form.for(key) API — I'm having a rather hard time coming up with a good/non-contrived example of what to use it for. (The current example has 'something went wrong' suggesting a 5xx error, but in that case surely you wouldn't return at all?)

For validation errors it feels like you could rely on client-side validation (including things like minlength) for the vast majority of things. AFAICT you only really need an independent result property when you need to show validation errors/previously-submitted data, can't use client-side validation to prevent the bad submission in the first place, and need per-instance UI. I'm sure those cases do exist but I'm having such a struggle thinking of a realistic one that I'm just going to punt on it for now and remove that section of the docs

[Rich-Harris]

I think we need to come up with a better name than formAction. It's weird for that object to contain a formAction property, and also weird that something called formAction contains a bunch of other properties. It also feels a bit weird to pick the camelCased property name over the lowercased attribute name, when the attribute is the thing that gives forms their magical progressive enhancement powers.

Looking at MDN, the only obvious alternative is override, though that's perhaps a bit overloaded.

(I'm tempted to suggest just throwing formaction onto the form object itself, alongside action, so that you can use it on a <form> or a <button>. That might offend purists though.)

Also we should probably have formmethod on there as well

[dummdidumm]

AFAICT you only really need an independent result property when you need to show validation errors/previously-submitted data, can't use client-side validation to prevent the bad submission in the first place, and need per-instance UI

In other words you already know when it's valuable - so we shouldn't remove it. One example are validation errors that happen on the server, like "you are not allowed to delete this". Another is to disable the button while a submission is in progress (which we need to add anyway AFAICT).

Related: #7175

I'm tempted to suggest just throwing formaction onto the form object itself

Sounds tempting indeed. I fear that the onclick handler intercepting unexpectedly could throw people off, also it would probably confuse people why there are more attributes than necessary on the form.

When coming up with an alternative name I would then choose something that is not an attribute name, that somehow brings across the intent. secondaryAction or something like that.

[Rich-Harris]

Yeah, not suggesting removing for, just the docs for for until we can come up with a good example.

Consensus on naming appears to be formAction -> buttonProps, will make that change

[dummdidumm]

Re example: what about pending UI which is made possible through a new Boolean (which we should have anyway) form.submitting?

[Rich-Harris]

Ooh that's a good idea. In the interests of shipping I think it should probably be a follow-up PR but yeah I like that

[Rich-Harris]

incredible work. lots more stuff to add in follow-up PRs but this is such a good foundation for everything to come