Is there a way for SvelteKit components to have corresponding endpoint files? - forms

Question

I have a SvelteKit Component that needs a corresponding +page.server.ts for cookie authenticated form actions. My goal is to have a Component with a corresponding delete button that will send an API request to my backend from within a form action inside a +page.server.ts endpoint.
My structure for some clarity:
- src/
- components/
- Component/
- +page.svelte
- +page.server.ts
- routes/
- route/
- +page.svelte
Component +page.svelte:
<div class="card">
<form method="POST">
<input type="hidden" value="{uuid}" name="uuid" />
<button class="btn-icon variant-filled-primary">
<span><Icon icon="material-symbols:delete-outline"></Icon></span>
</button>
</form>
</div>
Component +page.server.ts:
import type { Actions } from './$types';
export const actions = {
default: async ({ cookies, request }) => {
// Doing some http-only Cookie authenticated fetching and data processing here
}
} satisfies Actions;
The component is being rendered as perfectly fine as it did when I was still using just Component.svelte as my structure/nomenclature without a dedicated folder and +page.svelte.
The error I'm getting from within my browser after clicking the submit button in the component goes as follows:
405 POST method not allowed. No actions exist for this page
I figured this behaviour may appear since I don't have any form actions specified for my Routes +page.svelte but for my Components +page.svelte which, for whatever reason, won't be executed when clicking the form submit button.
Is my approach to this problem even possible of a solution or am I being forced right here to roll back and just use Route Form Actions from within every single route that utilizes my component? Doesn't seem like a very scalable option to me.

Answer 1

One thing to keep in mind with Sveltekit is that you get a lot of "magic" in the name of keeping things easy to use and on the happy path. The whole framework is designed around that premise and makes use of conventions to get it done.
Your src/routes directory is a convention that the whole router is built around, so anything that needs to execute routing behavior out of the box needs to be inside that directory. However, you still have a large amount of flexibility in how it all gets put together. In this case you have a couple of options.
Options 1: API Routes
As people have mentioned in the comments, you can use the routes directory to build out an API structure independent of any .svelte files that will render. A common structure would be something like this, which would create a standard endpoint route:
- src/
- routes/
- api/
- delete/
- +server.js
Inside the +server.js file you can build out standard handlers for GET, POST, etc. Then you can call the endpoint as a relative path from the root path, anywhere in the app and from any component using fetch, and you can also call it from other +page.js and +*.server.js files. In this case the route is reached with the path /api/delete.
Option 2: Co-locate components with routes
Another option if the component only relates to one route is to co-locate the component in the routes directory. If it doesn't have the + prefix it will be ignored by the router. This makes the following structure valid:
- src/
- routes/
- route/
- FormComponent.svelte
- +page.svelte
- +page.server.js
- utilities.js
In this case, both the FormComponent and the utilities files are ignored by the router, but both are still accessible from other files in the route. In cases where you need to decompose pieces of a page for reuse in that page, but those pieces only apply to the route in question, this can massively simplify your dependency map between files. Note that files placed in routes using this pattern can still be used elsewhere with standard relative path imports, but if you need to access them somewhere else they are probably better off living in the $lib directory.
A note about the official docs
I have found that the official docs are complete, but are also very succinct. There isn't a lot in the way of code examples, just enough to get you going. It's a great resource for reference but it can be challenging for discovery. Also an understanding of vanilla Svelte is assumed throughout, along with an understanding of HTTP conventions and web standards.
With that in mind, asking question here is encouraged, along with the official Svelte discord community which also covers Sveltekit. I've also found the Reddit community to be very helpful.