Spark & Anvil Privacy

Ages 15–18 · Grades 9–12 · Computer Science

StateForge

Read the state, then predict the screen.

Modern apps don’t draw the screen and then edit it — the screen is a function of the state: change the state, and the screen recomputes itself. Here you read a typed struct state and a declarative view and reason about it: what screen does it show? Tap a control — what shows now? And when a stored value goes stale after an event, redesign it — derive, don’t store a value you can compute, so there’s no stale copy to forget.

The state is a teaching subset of the Swift language (a teaching dialect, not SwiftUI); the puzzles are original teaching examples. Runs on your device — nothing leaves it.

Loading the state lab…

A case · you decide

Noor's cart badge that lied

Noor, 16 — building a shopping-list app whose badge shows how many items are left to buy

The idea in play: the screen is a function of state — store the facts once and derive everything else, so nothing on screen can go stale.

Noor stores the list of items and, separately, a number called `remaining`. When an item is ticked, she lowers `remaining` by one. After deleting a ticked item, the badge says 3 while the list clearly shows 2 left.

Two pieces of state now describe the same fact. Every event has to update both, and one path forgot.

If the badge is computed from the list each time it is drawn, it cannot disagree with the list.

What is the cleanest fix?

Noor also wants a "Done!" banner when nothing is left. Where should that come from?

Reason about state →

More ways to play

The vending automaton

What next? Pick a door

Chosen from what this app is about. What you open is remembered on this device only.