Text to UI

Text-to-UI Engine: Design at the Speed of Thought

The Text-to-UI Engine is the core innovation of Vinyasa. It allows you to define user interfaces using a simple, human-readable language called YAML. This "Design as Code" approach brings the power of software engineering—precision, reusability, and AI compatibility—to the world of UI design.

Visual editing supports exploration; YAML makes the document structure inspectable.

1. Explicit properties: Set supported coordinates, dimensions, text and colors, then validate the result. Frame layout can determine child positions, so inspect the owning layout before changing coordinates.
2. Focused AI proposals: Ask a configured assistant for a bounded change. Models can make mistakes; review the diff and validation feedback before applying.
3. Deliberate revisions: Change supported values while preserving stable IDs and page ownership. Avoid broad find-and-replace operations that accidentally change unrelated text or IDs.
4. Structured review: Keep document YAML for readable diffs and .rvv backups for continued editing. See YAML and Git.

Open YAML and AI from the editor rail. The document workspace has YAML, AI Copilot, and Review views. The YAML source supports highlighting and completion from the same catalog as the property inspector. Validate YAML checks the document without changing the canvas. Apply to canvas validates and replaces the canvas as one undoable edit. Errors are shown without applying the draft. An empty or invalid draft is kept for editing rather than silently overwritten.

A document contains an elements array. Compact examples receive IDs, a default page, and workspace settings during validation. Full editor YAML also preserves schemaVersion, pages, and settings.

elements:
  - type: button
    id: save-button
    left: 80
    top: 80
    text: Save
    width: 120

Properties are type-specific. Check the element reference rather than assuming CSS property names are accepted. Both frame and user-group support children. Top-level elements use workspace coordinates; nested children use local coordinates, and row/column frames manage placement. A window or card does not automatically contain nearby objects.

This compact example places top-level elements over a window surface. They remain siblings, not children of the window. For a nested form and a complete linked journey, inspect the authentication example and frame reference.

elements:
  - type: window
    left: 200
    top: 100
    width: 350
    height: 450
    fill: '#ffffff'
    text: Secure Login
  - type: circle
    left: 335
    top: 180
    radius: 40
    fill: '#f1f5f9'
  - type: text
    left: 275
    top: 240
    text: Welcome Back
    fontSize: 20
    fill: '#0f172a'
  - type: text
    left: 230
    top: 290
    text: Email Address
    fontSize: 12
    fill: '#64748b'
  - type: input
    left: 230
    top: 310
    width: 290
    text: [email protected]
  - type: button
    left: 230
    top: 380
    width: 290
    text: Sign In
    fill: '#087f75'
    textColor: '#ffffff'

Copilot uses Gemini, OpenAI, Anthropic, or an OpenAI-compatible endpoint. Configure the model and actual context window, give consent, and request one focused change. The agent inspects schemas and relevant objects, then produces a proposal. Review its diff and choose Apply proposal or Discard; generation never automatically changes the canvas. External assistants can also produce YAML that you paste into the YAML view. See AI setup, prompt recipes, and large-document editing.

Synchronization is explicit, not automatic. Reload from canvas captures visual edits; if the draft or a proposal would be discarded, confirm first. Apply to canvas sends a validated YAML draft to the canvas. If the canvas changes after the draft was loaded, the workspace shows Canvas changed and blocks applying the stale draft until reload. Closing and reopening the drawer keeps the current project's draft in tab memory. A page refresh does not preserve unapplied drafts. Back up applied projects using RVV exports and Git.