Svelte / Basic: reactive components and ownership / Lesson 1

Compiler, components and SvelteKit boundaries

Separate Svelte component compilation from SvelteKit routing, server execution and domain policy.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Explain the roles of .svelte files, the compiler and the application framework.
Distinguish local JavaScript evidence from unexecuted component and server behavior.

A component compiler is not the whole application

Svelte compiles component source into runtime behavior for a chosen target. A .svelte component combines script, markup and scoped styling, while SvelteKit adds routing, data loading, server endpoints and deployment integration. Neither layer automatically provides object authorization or durable storage. A learning portal can render a public course card with Svelte and obtain its eligible data through a SvelteKit server boundary. Start by naming the public representation, authoritative source and permitted caller before choosing component state. A familiar folder name or a successful compilation does not prove that the correct tenant’s data reaches the page.

Read a small runes-mode component

The fragment accepts one course prop with $props and displays two selected public fields. Runes are compiler-recognized syntax, not ordinary functions that can be tested by calling similarly named JavaScript helpers. The supplied course must already satisfy source and audience policy. This course selects Svelte 5 runes mode for new examples and SvelteKit 3 concepts for the application layer; it does not claim every legacy component must be rewritten at once. No Svelte package, compiler or browser was used to render the fragment, so its output is a reasoned reading of the declared input contract.

svelte Illustrative Svelte 5 public card

<script>
  let { course } = $props();
</script>
<article>
  <h2>{course.title}</h2>
  <p>{course.summary}</p>
</article>

The parent supplies an approved course view model. This fragment was not compiled and proves no request or permission behavior.

Identify where code executes before using an API

Component code can participate in server rendering and browser hydration. A browser API is not available merely because the file contains interactive markup. SvelteKit server-only modules, universal load functions and server loads have different execution and serialization boundaries. Keep credentials and private source clients out of modules imported by the browser. Rendering should derive output rather than perform irreversible writes because it can occur during prerendering or repeated navigation. Use explicit actions or endpoints for mutations with current authority, runtime input validation and a separate replay/transaction contract.

Test one public shape without a compiler

The local function returns a fresh card object and leaves an internal note out of the result. Its assertions are complete plain JavaScript and do not require Svelte. This establishes the helper’s chosen output keys only; authentication, source eligibility, template escaping and serialization remain separate. A server-only source can still leak private data if the helper deliberately returns it to a page. Do not serialize an entire persistence object just because a component can read its properties. A small projection makes the intended audience reviewable before any framework integration.

javascript Complete offline public-card projection

function card(record) {return {id:record.id,title:record.title,summary:record.summary};}
const value=card({id:"c1",title:"Svelte foundations",summary:"Public lab card",internalNote:"private-lab"});
console.assert(value.id==="c1" && value.summary==="Public lab card");
console.assert(!Object.hasOwn(value,"internalNote"));

The selected keys are returned and the internal note is absent. No Svelte render or authorization decision is executed.

Keep version assumptions and evidence explicit

Official Svelte 5 and SvelteKit 3 documentation was reviewed on 2026-10-28. These selected major-version concepts are not a claim to the latest patch or every newer optional feature. Pin compatible Svelte, Kit, Vite, adapter, TypeScript and runtime versions for real integration. Later 5.x/3.x additions need their own exact-version checks. All framework blocks remain runnable:false, and plain models do not emulate compiler scheduling or server infrastructure. This course installs no packages, starts no development server and contacts no configured source, database, queue or hosting service. Future verification should state which boundaries actually ran.

Common errors and fixes

A rune is treated as a normal imported JavaScript function

Why it happens: Compiler-recognized syntax was confused with an ordinary runtime API.
How to fix it: Use runes only in their documented compiled contexts.
Prevent it next time: Separate plain-function tests from actual compiler checks.

An interactive component uses window during server evaluation

Why it happens: Markup interactivity was assumed to make all code browser-only.
How to fix it: Move browser integration to an appropriate lifecycle or guarded boundary.
Prevent it next time: Test server rendering and browser behavior independently.

A public page receives private persistence fields

Why it happens: An entire source entity was returned without audience projection.
How to fix it: Authorize the object and return an explicit public model.
Prevent it next time: Assert exact output keys and denied-object behavior.

Check your understanding

1. Does the card helper prove that the displayed Svelte component is secure?

Show worked solution

No. It proves one plain function’s selected fields for a synthetic record. It does not verify authentication, object eligibility, compiler behavior, escaping or server/client boundaries. Keep the narrow evidence and separately verify the actual application path with safe identities in an authorized isolated project.

2. Why should irreversible writes not happen during rendering?