Tabs Component: Add Workflow Trigger on Tab Selection

[nocodeandy]

Allow the Tabs component to trigger workflows on tab selection, enabling builders to run actions (clear values, set fields, update state) without sacrificing the component's native active/selected visual state.

Summary

The Tabs component offers a polished, responsive navigation experience and has become the preferred replacement for workarounds like underlined Choice menus with profile-stored values and visibility conditions. However, it currently has no way to trigger workflows when a tab is selected. Builders who need to execute actions on tab change — clearing values, setting fields, updating user state — are forced to abandon the Tabs component entirely in favour of Buttons, which support workflow triggers but lack any native active/selected state. This creates an unavoidable tradeoff between interactivity and visual clarity.

Current Problem

• The Tabs component has no mechanism to attach a workflow or action to a tab selection event.
• Builders managing complex apps often need to reset or set field values when a user navigates between tabs (e.g., clearing a search filter, resetting a form state, updating a context variable).
• The only current workaround is to replace Tabs with Buttons, which support workflow triggers but have no native active/selected state — making it impossible to clearly indicate which "tab" the user is currently viewing without adding additional UI elements (e.g., separate indicators or conditional icons).
• These additional elements clutter the interface, undermining the clean, intentional design that the Tabs component is built to deliver.

Examples/Scenarios

• A builder has a multi-tab interface (e.g., Overview, Activity, Settings) and needs to clear a search field and reset a filter value each time the user switches tabs. Currently, there is no way to do this within the Tabs component.
• A complex app stores contextual state in user profile columns. When a tab changes, several fields need to be set or cleared to ensure the correct data is scoped to the active view. This logic currently requires a Button-based layout with custom active-state indicators bolted on.
• A builder replaces Tabs with Buttons to gain workflow support, but must add visible "selected" markers (e.g., a coloured bar, a conditional icon) for each button to simulate active state — adding components, increasing visual noise, and degrading the overall UI quality.

Why This Matters

• The Tabs component was introduced to replace fragile workarounds (Choice menus + profile columns + visibility conditions), but without workflow support it cannot fully replace those patterns in complex apps.
• Builders are being forced into a new workaround — Buttons — that trades one limitation for another, with no clean solution available.
• Active/selected state is a fundamental UX affordance in tabbed navigation. Losing it degrades the perceived quality and usability of the application.
• Workflow triggers on tab selection are a natural extension of how other interactive components (Buttons, Choice, etc.) already behave in Glide. Tabs are currently the only navigation-oriented component with no action support.
• This is an update-consumption-acceptable tradeoff for builders: the builder community has clearly signalled willingness to spend updates in exchange for proper UX integrity.

Suggested UX

• Workflow Trigger on Tab Selection
  • Add an "On select" action slot to each tab in the Tabs component, consistent with how Buttons expose action configuration.
  • Builders can attach any supported workflow or action sequence (Set column values, Run workflow, etc.) to individual tabs.
  • Trigger fires when the user taps/clicks a tab, before or alongside the tab's navigation behaviour.
• Update Consumption Transparency
  • If workflow triggers consume updates, surface this clearly in the builder UI (consistent with how other action-bearing components communicate update usage).
  • No guardrails needed — builders have explicitly indicated update consumption is acceptable in exchange for this capability.
• Preserve Native Active State
  • The selected/active visual state of the Tabs component must be fully preserved regardless of whether a workflow is attached. The action layer should be additive, not a replacement for built-in tab behaviour.
• Optional: Global Tab-Change Hook
  • As a complementary enhancement, consider a single "On any tab change" workflow slot at the component level (in addition to per-tab actions) for shared logic that should run regardless of which tab is selected.