@orion-front/docs

Appearance

Tabs panel ​

Purpose and problems it solves ​

tabs organizes several child panels in the same region while rendering one child at a time. It reduces visual density without losing each child's own configuration.

When to use it ​

Use Tabs when users switch deliberately between peer views. Use Group when views must remain visible together, and Condition when state, not a user click, should choose the child.

Prerequisites, inputs, and ownership ​

Each child requires a unique panel id, its normal variant configuration, and tab.label. Give every new tab a stable tab.semanticKey when the same logical view can occur in more than one Tabs container.

Capability map ​

  • localized tab labels;
  • one recursively rendered child at a time;
  • conditional filtering of candidate tabs;
  • exact selected-tab memory per outer Tabs id;
  • semantic tab restoration across different Tabs containers;
  • legacy label-based semantic restoration.

Behavioral model and interactions ​

Tabs filters conditioned children first. It then chooses a visible tab in this order:

  1. a child matching the last user-selected semantic key;
  2. the exact child id remembered for this Tabs container;
  3. the first currently visible child.

An explicit user click updates the exact tab, remembered semantic key, and the identity of the active Tabs container. Passive restoration does not overwrite that user-intent memory. If the current tab is filtered out, the same resolution order selects a surviving child.

Conditions use the Group/Tabs filtering model: unconditioned children remain; variables and objectSelected may include a child; default is not a Tabs fallback and is filtered out. An objectSelected child may set objectTypeNames to remain visible only for an exact selected-object metatype; this is the same matcher used by Condition and Group.

Alternatives, defaults, and precedence ​

  • tab.semanticKey is the canonical semantic identity.
  • If it is absent, runtime derives a compatibility key from tab.label. Localized label objects are normalized by sorted locale keys.
  • If no selection can be restored, the first visible child wins.
  • An empty or fully filtered panels array renders no tab content.

Changing a label on a legacy tab changes its fallback identity. Stable semanticKey values avoid that coupling.

Limitations and runtime drift ​

  • There is no configured default-tab field; ordering controls the first fallback.
  • Tabs does not lazy-load data explicitly, but only the selected child is mounted, so child lifecycle and request state can change as users switch.
  • The current verified fixture declares semantic keys in one container; it does not prove cross-container restoration.

Minimal valid configuration ​

json
{
  "id": "details-tabs",
  "type": "tabs",
  "panels": []
}

Realistic end-to-end scenario ​

The two stable semantic keys keep the logical tabs identifiable even if labels are translated or child IDs differ in another object's Tabs container.

json
{
  "id": "order-details-tabs",
  "type": "tabs",
  "panels": [
    {
      "id": "order-summary",
      "type": "message",
      "tab": {
        "label": {
          "ru": "Сводка",
          "en": "Summary"
        },
        "semanticKey": "order-summary"
      },
      "content": {
        "text": "Краткая информация о заказе"
      }
    },
    {
      "id": "order-operations",
      "type": "table",
      "tab": {
        "label": {
          "ru": "Операции",
          "en": "Operations"
        },
        "semanticKey": "order-operations"
      },
      "request": {
        "metaTypeName": "Operation"
      },
      "columns": [
        {
          "attribute": "name",
          "label": "Операция"
        }
      ]
    }
  ]
}

Verified demos ​

Open a two-tab composition with semantic keys Open nested tabs for object and edit-mode views

Exact parameter reference ​

Read Condition before adding conditioned tabs. Use Group inside a tab when that one view needs several simultaneous child panels.