Tab Component

Tab organizes parallel content for the same business object or workflow. Users can switch between content areas without leaving the current page. It works well for record maintenance, staged configuration, detail grouping, and edit-and-review workspaces.

After reading this guide, you will be able to:

• Add a Tab container and multiple tabs
• Configure Line, Card, and Editable Card appearances
• Place tabs at the top, right, bottom, or left
• Configure centering, disabled states, and deferred first rendering
• Combine Forms, fields, buttons, and other containers across tabs
• Configure onClick for an individual tab or the outer Tab container

Use Tab only for parallel views within the same object. Use page menus for separate business modules or pages that require their own URL, permissions, or menu highlight. Do not use a large number of tabs as a substitute for application navigation.

1. Example: Campaign launch workspace

The Tab page in Spark Sample uses a campaign launch workspace to demonstrate a common setup:

Tab	Content	What it demonstrates
Overview	Campaign name, owner, launch date, budget, and summary	Standard form editing and saving a draft
Delivery settings	Channel, audience, approval switch, default language, and delivery notes	Select, Switch, and configuration validation
Review & publish	Read-only summary and publish button	Deferred rendering, cross-tab form state, and interactions
Audit log (coming soon)	Not available yet	A disabled tab

This example does not depend on a backend Sample API. Field values remain in the current page state, making the example useful for learning Tab structure, switching, and interactions. To load business data, add Data Form, DataList, ProTable, or another data component inside a tab.

2. Add a Tab container

1. Open the target page in Page Designer.
2. Expand Containers in the component panel on the left.
3. Drag Tab into Screen or another area that accepts container components.
4. Select the Tab container and add tabs in the Tabs child-element area.
5. Select each child Tab and enter its Tab Label.
6. Drag a Form, fields, buttons, or other containers into the corresponding tab content area.

The Tab container and its child tabs form a two-level structure:

Tab
├── Overview
│   └── Form
├── Delivery settings
│   └── Form
├── Review & publish
│   └── Form
└── Audit log (coming soon)

3. Configure the Tab container

Select the outer Tab container and configure these properties:

Property	Values	Description
Tab Style	line, card, editable-card	Line emphasizes the active tab with an underline; Card uses card-style tabs; Editable Card uses the editable-card appearance only
Tab Position	top, right, bottom, left	Sets where tab labels appear relative to the content area
Center Tabs	On / Off	Centers labels when tabs are at the top or bottom; left and right positions remain vertical

At runtime, editable-card does not allow end users to add or remove page structure. The number and order of tabs remain managed in Page Designer, and runtime hides structural add and close controls.

After you choose a style or position, the design canvas immediately previews the same direction and primary appearance. Save the page to apply the saved configuration at runtime.

4. Configure an individual Tab

Select a Tab in the Tabs child-element list to configure:

Property	Description
Tab Label	The label displayed on the tab; keep it short and make the content scope clear
Always Render	When enabled, renders the tab content during initial page load; when disabled, renders it the first time the user opens the tab
Disabled	Prevents the tab from being selected; useful for content that is coming soon or unavailable under current conditions

4.1 Choosing Always Render

• Enable it when the form has few fields or tabs must share state immediately.
• Disable it for tabs with many charts, remote lists, or heavy components to reduce initial loading work.
• Disabling it delays only the first render. After a user has opened the tab, regular switching does not automatically clear entered values.

4.2 Choosing Disabled

A disabled tab still shows its label, but it does not switch content or run that Tab's onClick. If content should never be accessible, delete or hide the corresponding structure. Use Disabled for content that is temporarily unavailable.

5. Organize content in Tabs

A Tab can contain multiple Panels, Forms, and fields. Follow these guidelines:

1. Give each tab one clear topic.
2. For form content, add a Form first and place fields inside it so columns, label proportions, layout, and validation remain consistent.
3. Put the page's primary action on the final review tab or in a fixed area instead of repeating it on every tab.
4. Disable Always Render for tabs with heavy data lists.
5. If there are more than five to seven tabs, revisit the information architecture. Move low-frequency content into groups, drawers, or separate pages.

In the example, Overview and Delivery settings use editable Forms, while Review & publish uses a read-only Form with the same field names. When users update values in the first two tabs, the review tab reads the same page state and displays the latest values.

6. Configure interactions

Tab supports two levels of click interaction:

1. onClick on an individual child Tab.
2. onClick on the outer Tab container.

To configure an individual tab interaction:

1. Select the target Tab on the canvas or in the child-element list.
2. Open Interaction on the right.
3. Under onClick, add a Toast, update page context, call an API, or add another action.
4. Save the page and verify it at runtime.

When a user selects an enabled tab, the system runs the child Tab's onClick first and then the outer Tab container's onClick. Disabled tabs do not run click interactions. In the example, Review & publish shows a message when selected, and its button has a separate publish message.

7. Recreate the example

Use the following sequence to reproduce the Spark Sample page:

1. Add a Tab and keep line, top, and non-centered settings.
2. Add Overview, Delivery settings, Review & publish, and Audit log (coming soon).
3. Add one Form to each of the first three tabs and use a two-column Horizontal layout.
4. Add Input, DatePicker, TextArea, and a Save draft button to Overview.
5. Add Dropdown Select, Switch, Input, TextArea, and a Validate settings button to Delivery settings.
6. Add read-only fields and a Publish campaign button to Review & publish, and disable Always Render for this tab.
7. Set Audit log (coming soon) to Disabled and disable Always Render.
8. Add an Info Toast to the onClick of Review & publish.
9. Add a Toast to each of the three action buttons and use component-value expressions in the messages, for example:

Campaign [[campaignName]] is ready for [[campaignChannel]].

8. Troubleshooting

8.1 Runtime does not reflect style or position changes

Confirm that the page has been saved and that the runtime URL uses the versionId for the current design version. The design canvas previews changes immediately, while runtime reads the saved Page JSON.

8.2 Clicking a tab does not run the interaction

Check the following:

• Interaction is configured on the actual child Tab, not on a Form inside the tab.
• The event is onClick.
• The Tab is not Disabled.
• The page has been saved and runtime is using the current version.

8.3 Field values disappear after switching tabs

First confirm that each field has a stable, unique Name. When the same value must appear across tabs, the editable and read-only areas should use the same field Name. Different Names represent independent page state.

8.4 Initial page load is slow

Disable Always Render for non-initial tabs that contain remote lists, charts, or many fields. Keep only essential content on the first tab and create the remaining content when users first open it.

9. Design recommendations

• Use nouns or short action phrases for tab labels, such as Overview, Configuration, and History.
• Keep tabs in the same group at a similar information level. Do not place Details, System settings, and Sign out at the same level.
• Do not communicate important errors, unsaved state, or publishing results through tab color alone; provide readable text as well.
• On mobile, reduce the number of tabs whenever possible. Left and right positions are better suited to localized desktop workspaces.
• Use separate pages and menus when content needs an independent link, browser history, or menu permissions.