Skip to content

Answers use only the pages of this documentation, and every answer links to the pages it came from. Your question is sent to our answering service to be answered, and kept so the people who write these pages can see what readers ask.

🗂️ Screens

Every screen, its component hierarchy, and the element editor.

Screens lists every screen in your app, and drills into one to show what it is made of. Picking a screen also navigates the live preview to it, so the panel and the preview always agree.

The panel has three levels: the screen list, one screen’s detail, and the editor for a single element.

A search box filters the list by name. Below it, one row per screen.

When the list is empty the panel says why, and the three reasons are kept apart:

  • “No screens found yet — generate the app first.” The app genuinely has no screens.
  • A load error message. The screens could not be fetched. This is not the same as an app with no screens, and the panel does not pretend it is.
  • “No screens found” Your search matched nothing.

Selecting a screen opens its detail view and points the preview at the matching route. A back arrow labelled All screens returns to the list.

At the top is the screen’s name, with an Ask Ada button beside it. That button starts a chat message already scoped to this screen — “On the Checkout screen, ” — so you can describe a change without explaining where it goes.

Four sections follow.

The component hierarchy, shown as a nesting tree with disclosure triangles, the same shape as the classic editor’s Layers. Every parent is expanded when you open the screen, and Expand All / Collapse All are in the section header.

Each row shows two things: the kind of component, and its text or tag. Kinds are grouped into plain words rather than code names, so you see Text, Image, Button, List, Input, Map, Icon or Container rather than the underlying element.

Clicking any row opens the element editor for it.

If the screen takes an id from the route — a product page, an order detail — the preview cannot know which record you mean, so it renders with sample data and the section says Previewing with sample data.

The data this screen fetches when it opens, listed as a kind and a name. This is read-only: it describes what the screen already does.

If the screen fetches nothing, it says so.

Values the screen reads from the route and from app state — the id it was opened with, the signed-in user, and so on. Also read-only.

The route this screen answers on, for example /checkout or /plan/__preview__ for a screen that takes an id.

Some screens are not routes at all. An auth gate rendered by the app layout has no address of its own, and the section says so rather than inventing one.

Clicking a component in the tree replaces the panel with the editor for that element. A back arrow returns you to the screen.

The header names the element, and above it a trail shows the screen and the two containers it sits inside — for example Checkout › Card › Row. Without that trail a selected “Text” tells you nothing, and there is no way to tell a heading from a button’s label.

A ⋮ menu in the header offers Delete element.

Edit the words on the element.

Three cases are handled differently:

  • Plain text. A single field.
  • Text that changes by condition. Each version gets its own field, labelled Option 1, Option 2 and so on, under the note “This text changes by condition — edit each version”.
  • Text that comes from data. Not editable here. The panel shows what it is bound to, because the words are a record’s, not the screen’s.

If your app has more than one language, a note says which translation you are editing — for example Editing the FR translation. You are editing that language’s string, not the source text.

Every style attribute already set on the element, each with the right control for its type — a color picker for colors, a number field for sizes.

Add attribute… adds one that is not set yet. Each option in that menu carries a plain description, so you are choosing “Space inside the element, on all sides” rather than remembering what padding means. The available attributes cover fill and text color, font size, weight, line height, letter spacing, alignment, capitalisation, padding, margin, corner radius, border, opacity, width, height, gap, stacking direction, alignment of children, and shadow.

When a style or prop uses one of your brand colors, a toggle appears with two options:

  • Everywhere — changing the color updates the brand color across the whole app.
  • This element — the change affects only this element.

This is the difference between restyling your app and making one exception, so the panel states which one is active underneath the toggle.

Settings on the component that are not styles. Same idea as Styles, with an Add prop… menu. The section only appears when the element has props you can change.

What the element does when it is used — its handlers, each with a short summary. Read-only, and shown only when the element has any.

A text box at the bottom of the editor. Describe a change in words and send it to the chat, already scoped to this element. Use it for anything the controls above cannot express, such as “make this a button that opens settings”.

Some elements cannot be edited directly at all. For those the panel says so plainly and leaves this box available, since Ada can still change them.

Save Changes at the foot of the editor applies everything you changed. It stays disabled until something is different.