Guide
The power of the declarative graph
Six short steps, each running live. You will build a bookshelf app, connect its screens with a label, write records through the pipe, change its theme, add social components that connect themselves, and then see how much of it the engine can infer.
Everything you add in these examples is saved in this browser; nothing leaves your device.
Declare a state
A state is a screen. Its children lay themselves out by implied containment: a GRID puts things in columns, a ROW puts them side by side, and everything else stacks. Layout needs no stylesheet or layout code.
Wire two states by label
Move the books into DATA and let CARDS draw one card per record. Clicking a card fires the label open. A WIRE with the same label says where open goes. The clicked book travels with the transition, so the next state reads it as {record.title}.
Write through the pipe
Every action carries a key-value bag, the pipe: each field on the screen under its ID, plus system keys such as the user and the time. A wire with SAVE turns the pipe into a record. Add a book below; it is saved in your browser and the list updates by itself.
Swap the theme
A theme is one attribute on APP. Every colour, radius and typeface changes together, and every component follows because components are written only against the theme's tokens. Pick another theme from the list, or edit THEME yourself.
Add components that connect themselves
Add LIKES and COMMENT-THREAD to the book screen and make no other change. Each book now has its own likes and its own discussion. The spec never names a book: the components bind to the data asset the screen is showing, identified by its GUID (books/dune, books/piranesi), and the engine connects them.
Say less: the engine infers the rest
Every attribute you leave out gets a default inferred from names, data and context. A FIELD called title is labelled Title. OPTIONS make a select. FORM SAVE saves to a collection with no WIRE. OPEN makes a clicked item the active record and goes to a screen that gets its own back link. FILTER builds the pills from the data. Anything you write explicitly always wins.
The short form · 12 lines, as you would write it
The long form · 15 lines, every inferred attribute written out
Both are running. The long form is not written by hand: it is what the engine prints when asked to explain the short one (12 inferred values), and it is also valid AppSPEC. Studio shows the same thing: inferred values appear greyed in the inspector, and Source has an Expanded view.
Why it matters
Super-loose coupling
In step five the comments were not told which book they belong to, and the book screen was not told that comments exist. Each side depends only on the engine, which knows which data asset is on screen and connects the two.
This is how one comment component serves a video site, a store and a blog, and how likes can be added to any screen with one line.
Next
Keep going
Browse every component with a live demo, open a gallery app in the Studio, or read how the engine works.