Create a Svelte application by starting a SvelteKit project, building one page component and making its changing values explicit. Before the first deployment, test initial rendering and browser interaction as separate parts of the same journey. Keep a written record of the state that should change, the state that should reset and the environment you actually reviewed.
A first application should have a task that is easy to explain without mentioning the framework. This guide uses a fictional packing checklist: mark items packed, add an item and reset the exercise. It is small enough to inspect but still exposes component boundaries, nested state and the difference between a page loading and an interaction working.
The original acceptance sheet below gives the exercise a useful end point. It supports a review of the actual page and its first deployment while keeping later work, such as real accounts and stored business data, explicit.
How do you start the project and organise its pages?
SvelteKit’s project guide starts with npx sv create. The project-creation guide shows creating a new directory and starting the development server after dependencies are installed. Use a fresh project directory and record the choices made by the starter so another developer can repeat the setup.
The project-creation command asks about basic tooling such as TypeScript. Choose options that support the exercise and explain why you selected them. A beginner benefits from a small, coherent setup more than an unexplained collection of integrations. Retain the generated project instructions and check that the local runtime matches the selected version’s requirements.
SvelteKit pages are Svelte components. SvelteKit pages are created through files in src/routes. Begin with a page that displays the checklist and a small item-row component if separating it makes the responsibility clearer. Draw the boundary: the page owns the list and each row presents an item and its available action.
The project guide describes server-rendered pages followed by a client-side application taking over. Treat that documented sequence as two observations to make. First inspect what is available on the initial page response; then confirm that the browser-side controls work. A screen that looks complete before interaction and a screen whose controls work after loading are related but distinct checks.
How should the checklist use reactive state?
The state rune creates reactive state whose changes affect the UI. The state documentation shows a directly updated value rather than requiring a separate object-access API for the simple counter example. Apply the same clarity to the packing exercise: name the state after the task and make each user action’s intended change easy to locate.
Svelte makes arrays and simple objects passed to state deeply reactive proxies. An array of fictional items with a description and packed flag provides a useful example. Toggle one flag and confirm that only the intended item changes. Then add a fresh item and inspect whether its action behaves consistently with the original items.
Destructuring a reactive value does not preserve reactive references. This matters when moving a value into a helper variable for convenience. If an item’s status appears stuck, compare the expression used in the template with the source of the reactive value. Do not compensate by introducing repeated manual refreshes before understanding the broken relationship.
Svelte does not proxy class instances automatically. Keep the first exercise with simple data until a class has a clear purpose. The documentation explains how state can be used in class fields when that structure is needed. Avoid assuming that wrapping the surrounding list makes every possible object behave identically.
Svelte’s raw state must be reassigned rather than mutated. Choose between deeply reactive state and raw state deliberately. For the first checklist, document which model you used and why. A reviewer should be able to follow an update from the button action to the stored value and the visible result without guessing whether reassignment is required.
| Checklist behaviour | Proposed state decision | What the reviewer should observe |
|---|---|---|
| Mark an item packed | Update the selected item’s flag | Only that item changes status |
| Add an item | Add an approved description with a fresh flag | New item appears and can be toggled |
| Edit a description | Update the intended item | Other descriptions remain unchanged |
| Reset | Apply a written reset rule | Agreed fixture and statuses return |
| Open a fresh session | Apply the chosen persistence boundary | Starting state matches the stated design |
What should happen when the page starts again?
Decide what “reset” and “fresh visit” mean before adding storage. A reset might restore the original fictional list, whereas reopening the page might simply start the same exercise again. If persistence is outside the first project, say that in the project brief so the reviewer does not mistake temporary state for saved work.
Make the labels around the actions specific. “Reset checklist” is clearer than an unexplained icon, and “Packed” should have a readable state as well as a visual treatment. Include keyboard operation in the exercise. An interaction should remain understandable when the user is not following the pointer or relying on colour.
Keep invalid item descriptions within the design discussion. Decide whether a blank entry is rejected and how the message explains the correction. Avoid silently creating an empty row: it makes the list difficult to interpret and leaves the next developer to infer whether the behaviour was intended.
Original packing-checklist acceptance sheet
Use the fictional items “document pouch”, “charging cable” and “notebook”. The following are proposed checks, not observations from a deployed application. For each, record the expected state, observed state, environment and evidence.
Initial response: Open the checklist directly. Confirm that the expected initial content is present and readable. Record what is available before browser interaction, then confirm the controls become usable as intended. Capture the exact route rather than merely noting that the homepage opened.
Single change: Mark the charging cable packed. The proposed outcome is that its status changes while the other items remain unpacked. Navigate the controls with the keyboard and check that the action’s label remains understandable afterwards. Reset before the next case.
New item: Add “water bottle”, then toggle it. Confirm that the new row behaves like the original rows and that the update applies to the new item. Try a blank description against the agreed validation rule and retain the resulting message.
Reset boundary: Mark an original item and the new item, then use reset. Write down whether the new item is removed and whether the original statuses are cleared. Compare the observation with the agreed rule rather than assuming that any visually neat result is acceptable.
First deployment: Use the selected project’s documented build and hosting instructions for an isolated preview. Record the runtime or output requirement, route and revision. Repeat the earlier cases through that preview. If deployment needs configuration the exercise has not supplied, record it as specific remaining work with an owner.
What belongs in the first handover?
Retain setup choices, component responsibilities, state rules, build instructions and the completed acceptance sheet. Distinguish the environment reviewed from the environment merely proposed. Keep credentials out of example data and review the data boundary before connecting real services or enabling persistence.
A finished first exercise should be easy for a second person to open, change and reset deliberately. For wider project scope, see web development and hosting. To discuss the next application step, get started with the checklist brief, deployment record and the remaining behaviour you want to add.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.