Problem is that, for the most part, the way we use and build components is incompatible with Svelte SSR. More specifically one part - reactive statements (ie $:).
For an ideal SSR experience, we should make it an antipattern to have any reactivity (that might happen during SSR; prop reactivity is an exception) happen through reactive statements, and instead use derived stores and event handlers.
This is especially relevant in components that make use of <slot /> for composing their behaviour (DataTable is also the best example here, should also be the starting point for changes)
General translation guide:
$: var = something; should become const var = derived(something, ([$something]) => { ... });
$: if (state) { ... } should become an event handler for whereever state is being changed
chunky $: { ... }s should be broken down into chunks that should fall into one of the above 2 categories
can be expanded upon w/ exception cases when we start work on this
Problem is that, for the most part, the way we use and build components is incompatible with Svelte SSR. More specifically one part - reactive statements (ie
$:
).For an ideal SSR experience, we should make it an antipattern to have any reactivity (that might happen during SSR; prop reactivity is an exception) happen through reactive statements, and instead use derived stores and event handlers.
Example from
_DataTable
:should become
or something to that effect
This is especially relevant in components that make use of
<slot />
for composing their behaviour (DataTable is also the best example here, should also be the starting point for changes)General translation guide:
$: var = something;
should becomeconst var = derived(something, ([$something]) => { ... });
$: if (state) { ... }
should become an event handler for whereeverstate
is being changed$: { ... }
s should be broken down into chunks that should fall into one of the above 2 categoriescan be expanded upon w/ exception cases when we start work on this