Having Server Logic on components themselves (RSCs are not just for performance)

[TomDo1234]

Basically, I think its a good idea to have server logic for components for Sveltekit.

Yes, I understand that we have streaming which gives Sveltekit performance equal to RSC. However its not always about the performance.

Imagine a component which inherently makes the same database query, such as a component displaying the amount of visits the site has all the amount of cars that are in the database. I don't want to have to put that data and query on the page.server.ts every single page that has this component. I want the server logic to be part of the component itself. That keeps things encapsulated and free from me having to jam the query into the page server ts , then pass things in as props or god forbid a store. This is especially useful if for example your "Amount of Cars" component runs 5 levels down the component tree from the +page.svelte. Allowing server logic on components leads to more freedom and can allow for more robust programs that are easier to read and reason about.

I think it will lead to more options for the developer to design their application, and can lead to better designed and more modulated components and application logic. Potentially, you can even have caching as well, in order to load the component faster if it is rendered multiple times in the app.

If you want to go super crazy, you can even make it so that these "Server Components" (Or should I say, components with coupled server logic) can take props (Though these props are static and are decided by the developer at build time, so for example you can only put in constant expressions) and use those props for both their client logic and server logic.

A super duper crazy idea would be to not constrain the props to constant expressions, so they can be dynamic during runtime, and every time a prop changes Svelte detects a change in the prop the same way it detects changes in a reactive expression's dependency, and then rerun server logic.

All in all, regardless of whether you agree with the crazy ideas of the 2 preceding paragraphs, I believe that at the very least... Giving components its own server logic is the future. It is part of the reason I have been going back to Next 13 (App directory) at work. Fine, you can complain about "use client" all you want, but I am not advocating for full blown server components that do not have access to client side JS like how RSCs cannot have useState in them. Instead I am proposing allowing server logic, essentially a +page.server.ts from within a component itself. The component can still have its client side stuff like all variables being reactive, reactive expressions, onMount etc. Except there is a section inside the component where you can define a load function which runs on the server, before svelte serves the HTML and JS,CSS to the client. This way, nobody is gonna get confused like with React people having to remember to put "use client" on things. This server logic is just going to be an optional add on if the developer wants to design a component that has inherent server logic. If people want to stick to the good old page load methodology, they can stick to that.

[ctwhome]

All in for modularity and encapsulation here.