Screens, not just parts

Compose screens

Coming

Compose your components into full screens that render on both web and Flutter — and serve those same screens from a server when you want to change UI without shipping an app update. This is designed and documented here so you can see its shape; it isn't shippable yet.

Coming

Layout is designed but not yet available. This page describes the intended experience so you can plan for it — there are no working steps to run yet.

The layout primitives already exist

The @wyrd-company/layout-dsl schema currently defines component, container, flexContainer, grid, outlet, safeAreaContainer, scrollContainer. These building blocks are implemented even though the complete compose-a-screen authoring flow below is still coming.

The intended experience

You'll compose a screen by arranging components — by hand in code, or visually — into a single layout document. That one document renders on web and on Flutter, so a screen you compose once shows up faithfully on both platforms, the same way a component does today.

Because the screen is a document rather than baked-in code, your server can choose or generate it at runtime. Server-driven UI, generated UI, and A/B testing all become the same thing: picking which layout document to send.

The intended authoring artifact

A composed screen will be a layout document — a semantic description of which components go where, with their values and bindings — that round-trips cleanly between the visual editor and source.

Illustrative layout document (shape, not final)
{
  "type": "Stack",
  "props": { "gap": "md" },
  "children": [
    { "type": "Text", "props": { "value": "Welcome" } },
    { "type": "Button", "props": { "label": "Get started" } }
  ]
}