Tabs field

Use field.Tabs to divide a long editor into focused sections. A named tab stores its children under an object property; an unnamed tab changes only the admin layout and leaves child paths at their current level.

In the admin

Unnamed tabs alter layout only; named tabs add an object boundary to document paths.

Named and unnamed tabs

field.Tabs(
  field.UnnamedTab("Content",
    field.Text("title", field.Required()),
    field.Blocks("layout", field.BlockTypes(/* … */)),
  ),
  field.NamedTab("seo", "Search & sharing",
    field.Text("title", field.MaxLength(60)),
    field.Textarea("description", field.MaxLength(160)),
  ),
)

The resulting document has root title and layout properties plus a nested seo object. Choose named tabs when the object boundary is meaningful to API consumers; choose unnamed tabs when only the authoring experience needs separation.

Tab labels and LabelTranslations are admin-interface copy. They do not localize content. Configure Localized on stored child fields or on another nested container according to the value that actually varies.

Constraints and common mistakes

• Every tab needs a label and fields. Named tab names must obey field-name rules and be unique at that level.
• Presentation-only tabs do not grant access or change validation. Hidden fields still pass through the operation engine.
• Changing an unnamed tab to a named tab changes document paths and requires a migration. Changing only its label does not.
• For a few direct fields, the concise field.Tab("Label") option may be enough. Use Tabs when you want an explicit ordered set of sections or stored named objects.

See field.Tabs, field.NamedTab, and field.UnnamedTab.