Svelte Server Components

[outerlook]

Svelte Server Components

Great part of the concepts written here were stolen borrowed from React Server Components proposal.

This was written by a svelte user. I know when users want to play dev around things that don't understand well, things can get messy. But at least some conversation can be brought. Right now I am not aware of internals, but would be nice to know the blocking issues to build such feature.

Summary

There are mainly 2 ways of compiling then rendering a Svelte app - at server or at browser.

This proposes that efforts of defining "where should a component be rendering", "how should they be split", "what are the interfaces on this component splitting should be handled" entirely by the svelte language and not the tools that implements SSR / SSG.

There are different ways it could be told to the compiler how to differentiate. My suggestion is the same as React.

Component.svelte; Component.server.svelte; Component.client.svelte.

Motivation

When we create a component file, there are 3 possible kinds of requirements:

1 - Server Component

• We have used something that shouldn't be exposed (load from backend);
• We have included a module that is too big to be shipped (momentjs, marked).

2 - Client Component

• We have used some feature that is exclusive to browsers (window, navigator);
• Our component is someway interactive (on:click, etc).

3 - Whatever Component

• There are no requirements;

"Where to render" seems to be tackled by other tools (svelte-kit, elderjs, roxi's tools, etc...).

Each of these tools tries to address on their own ways partial-hydration for example. This creates a kind of race between these tools to define what kind of solution they provide to deal with:

• extracting a partial component of Svelte and then reassembling them;
• how to permit a developer to create a load() / data() function that won't be exposed to browser

Changing the responsibility of exposing exactly how and where should a component be compiled (an API) to the language would bring benefits to gather efforts toward a really common problem.

There could be less discussion on how to partial rehydrate. An svelte app with multiple roots could focus only on hydration without needing this concept of partial.

A more mature conversation around the issue can be found at React Server Components RFC that also applies to common problems to svelte.

Describe the proposed solution

Design (I tried)

Components:

Behavior

If child of a component is:

• Server or client kind: if parent is same type, continue compiling. If it isn't of the same type, split right here.
• Any kind: continue compiling, it's considered a generic

Communication between groups of components

Compiler would compile, split when encounters different kind of component and add to the resulting compilation:

• Compiled code;
• Entry points that were defined;

type Entrypoint {
	component: SvelteComponent;
	id: HashId;
	props: ComponentProps; // Props currently used and sent to the other environment;
	contexts: AvailableContexts; // Contexts made available by parents;
	expectedKind?: "server" | "client"
}

Who know best the current problems that could be addressed

I think the maintainers of the current svelte ecosystem tools could add much to this conversation.
I know there are some that addressed by their own ways some of these problems. That who didn't address have this issue on their backlog for sure.

How we teach this

It is a whole new concept. But I think it could avoid being a breaking change (or should it?).

But I guess it would fit well to unify frameworks terminologies and be a little bit more agnostic about how to structure an app.

Acceptance of this proposal as is is not required, but I think it would be healthy to discuss about it.

Drawbacks

It is a big responsibility to be brought to the compiler. Not addressing it would mean less to maintain. (Although I think the interface with frameworks would be smaller if it was builtin to compiler how to manage this kind of splitting)

Alternatives considered

Alternatives

Let tools address this issue.

Alternatives of how to define kind

Context module

<script context='module'>export const kind = "server" // or "client" </script>

The drawback would be the need to parse before knowing the kind. On file makes more sense to know by the file name without parsing.

Unresolved questions

• Where should end the responsibility of the compiler? Should serializing props/context be a problem?
• What would be the limitations? No bind / mutation of props for example
• How to interact with code outside components?

Importance

nice to have

keywords

islands architecture, partial rehydration, ssr, ssg, server components

[Conduitry]

Really open-ended proposals like this, where the end goal is not yet clear, should be written as an RFC in the dedicated repo. That said, I wouldn't expect much engagement over there either unless you had specific ideas of what to introduce, rather than just a general position that certain sorts of things ought to be handled in the language rather than by tooling.

[outerlook]

Alright, I guess my intention was to bring a discussion rather than an issue, then this is not the right place (and I know the proposal isn't complete to write an RFC out of it yet).

But as this didn't bring any attention at all, maybe my problems are not being the same as the most part of community seems to be facing right now. And that is ok.