fix(ui-core): unblock antd migration — optional Alert title, dashed Divider, disabled-trigger Tooltip

[chirag-madlani]

Three gaps in ui-core-components that are each blocking antd call sites from migrating. Separate commits, independently reviewable.

Found while sweeping Collate — every one of these turned a would-be mechanical migration into "leave it on antd".

1. Alert — a body without a title

title was a required string. antd's message is an optional ReactNode, and its description-only alerts have no heading at all. Of Collate's 11 alerts, only 2 had a plain string message — 6 passed markup, and 3 had no message whatsoever. Migrating those meant inventing user-facing copy.

title is now optional and takes a ReactNode. When absent, the heading element isn't rendered and the alert uses the single-block layout it already had for a title with no body, so the icon stays centred instead of top-aligned against a lone paragraph. Every existing call site passes a title (it was required), so nothing changes for them.

2. Divider — dashed, and a vertical rule with a height

• No dashed variant. A solid rule is a filled 1px box and a background can't be dashed, so the dashed case switches to a border and collapses the box in that axis. The rules either side of a label follow suit.
• The vertical rule had no intrinsic height. It relied entirely on self-stretch, which produces nothing outside a flex/grid parent and is overridden the moment a consumer aligns the divider itself — an unlayered LESS .self-center is enough to collapse it to zero and make it vanish silently. antd's vertical divider had an intrinsic height; min-h-[1em] restores that without capping the stretch case.

Between them these unblock 21 Collate elements.

3. Tooltip — open on a disabled trigger

A disabled control fires no pointer or focus events, so react-aria never opened its tooltip. That's backwards for the usual case: the tooltip is what explains why the control is disabled, and it vanished exactly when the user needed it. antd wrapped disabled children in a listener element for this reason.

A disabled child now takes the same auto-wrapping path as a non-focusable one, but via Focusable + a span rather than the AriaButton wrapper — the child is already a button, and nesting one inside another is invalid HTML and breaks clicks. The child is made inert so it stops swallowing the events the wrapper needs.

Two Collate sites sit on antd purely because of this, and QueryToolbar has the same latent bug on main today.

Verification

• 16 new tests (7 Alert, 6 Divider, 3 Tooltip); the Tooltip file's existing 12 still pass, so the new wrap path doesn't disturb the existing ones.
• Full core suite 110/111. The single failure (Table › can omit the selection cell for a full-width synthetic row) is pre-existing on clean main — verified by stashing this branch and re-running.
• tsc, eslint, prettier clean.

Note for reviewers

A fourth change was planned — making Button forward injected mouse handlers — and dropped after measuring. I'd assumed react-aria's filterDOMProps stripped them. It doesn't: onBlur, onMouseOver, onMouseDown and onPointerEnter all reach the DOM. Only onFocus is swallowed, which means an antd-wrapped core Button gets hover tooltips but not keyboard-focus ones. Real, but narrow, and not worth speculative surgery on Button's prop plumbing — raising separately if it's worth fixing.

Draft: happy to split further or adjust the Alert layout fallback if you'd rather it stayed top-aligned.

🤖 Generated with Claude Code

[gitar-bot]

⚠️ Bug: Dashed divider uses non-existent color token, renders wrong color

The dashed branch of ruleClasses sets the border color with tw:border-secondary, but no --color-secondary token exists — the token is border-secondary, so the color utility must be tw:border-border-secondary (mirroring the solid branch's tw:bg-border-secondary). As written, the border-color utility isn't generated and the dashed rule falls back to currentColor (the inherited text color), so every dashed divider — the whole point of this change — draws in the wrong, usually darker color. The tests only assert border-dashed/border-l, so they don't catch it.

Use the border-secondary color token via border-border-secondary.:

return axis === 'y'
  ? 'tw:w-0 tw:border-l tw:border-dashed tw:border-border-secondary'
  : 'tw:h-0 tw:border-t tw:border-dashed tw:border-border-secondary';

• Apply fix

_{Check the box to apply the fix or reply for a change | Was this helpful? React with 👍 / 👎}

[gitar-bot]

💡 Edge Case: Disabled-trigger wrap ignores excludeTriggerFromTabOrder

The disabled-child branch hardcodes tabIndex={0} on the wrapper span, so a disabled trigger that a consumer explicitly asked to exclude from the tab order (excludeTriggerFromTabOrder) is still keyboard-focusable, unlike the non-disabled wrap path which honors that flag. Consider deriving tabIndex from excludeTriggerFromTabOrder (e.g. tabIndex={excludeTriggerFromTabOrder ? -1 : 0}) for consistency.

_{Was this helpful? React with 👍 / 👎}

[gitar-bot]

Code Review ⚠️ Changes requested 0 resolved / 2 findings

Unblocks antd migration by making Alert title optional, adding dashed Divider support, and opening Tooltip on disabled triggers. Two issues must be fixed: the dashed divider uses a non-existent color token (tw:border-secondary should be tw:border-border-secondary), causing it to render in the wrong color, and the disabled-trigger wrap hardcodes tabIndex={0} instead of respecting the excludeTriggerFromTabOrder flag.

⚠️ Bug: Dashed divider uses non-existent color token, renders wrong color

📄 openmetadata-ui-core-components/src/main/resources/ui/src/components/base/divider/divider.tsx:41-43

The dashed branch of ruleClasses sets the border color with tw:border-secondary, but no --color-secondary token exists — the token is border-secondary, so the color utility must be tw:border-border-secondary (mirroring the solid branch's tw:bg-border-secondary). As written, the border-color utility isn't generated and the dashed rule falls back to currentColor (the inherited text color), so every dashed divider — the whole point of this change — draws in the wrong, usually darker color. The tests only assert border-dashed/border-l, so they don't catch it.

Use the border-secondary color token via border-border-secondary.

return axis === 'y'
  ? 'tw:w-0 tw:border-l tw:border-dashed tw:border-border-secondary'
  : 'tw:h-0 tw:border-t tw:border-dashed tw:border-border-secondary';

💡 Edge Case: Disabled-trigger wrap ignores excludeTriggerFromTabOrder

📄 openmetadata-ui-core-components/src/main/resources/ui/src/components/base/tooltip/tooltip.tsx:159-168

The disabled-child branch hardcodes tabIndex={0} on the wrapper span, so a disabled trigger that a consumer explicitly asked to exclude from the tab order (excludeTriggerFromTabOrder) is still keyboard-focusable, unlike the non-disabled wrap path which honors that flag. Consider deriving tabIndex from excludeTriggerFromTabOrder (e.g. tabIndex={excludeTriggerFromTabOrder ? -1 : 0}) for consistency.

🤖 Prompt for agents

Code Review: Unblocks antd migration by making Alert title optional, adding dashed Divider support, and opening Tooltip on disabled triggers. Two issues must be fixed: the dashed divider uses a non-existent color token (`tw:border-secondary` should be `tw:border-border-secondary`), causing it to render in the wrong color, and the disabled-trigger wrap hardcodes `tabIndex={0}` instead of respecting the `excludeTriggerFromTabOrder` flag.

1. ⚠️ Bug: Dashed divider uses non-existent color token, renders wrong color
   Files: openmetadata-ui-core-components/src/main/resources/ui/src/components/base/divider/divider.tsx:41-43

   The dashed branch of `ruleClasses` sets the border color with `tw:border-secondary`, but no `--color-secondary` token exists — the token is `border-secondary`, so the color utility must be `tw:border-border-secondary` (mirroring the solid branch's `tw:bg-border-secondary`). As written, the border-color utility isn't generated and the dashed rule falls back to `currentColor` (the inherited text color), so every dashed divider — the whole point of this change — draws in the wrong, usually darker color. The tests only assert `border-dashed`/`border-l`, so they don't catch it.

   Fix (Use the border-secondary color token via border-border-secondary.):
   return axis === 'y'
     ? 'tw:w-0 tw:border-l tw:border-dashed tw:border-border-secondary'
     : 'tw:h-0 tw:border-t tw:border-dashed tw:border-border-secondary';

2. 💡 Edge Case: Disabled-trigger wrap ignores excludeTriggerFromTabOrder
   Files: openmetadata-ui-core-components/src/main/resources/ui/src/components/base/tooltip/tooltip.tsx:159-168

   The disabled-child branch hardcodes `tabIndex={0}` on the wrapper span, so a disabled trigger that a consumer explicitly asked to exclude from the tab order (`excludeTriggerFromTabOrder`) is still keyboard-focusable, unlike the non-disabled wrap path which honors that flag. Consider deriving tabIndex from `excludeTriggerFromTabOrder` (e.g. `tabIndex={excludeTriggerFromTabOrder ? -1 : 0}`) for consistency.

Options

Display: compact → Counting what did not apply, without listing it.

Comment with these commands to change the behavior for this request:

Compact

gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Powered by Gitar — free for open source}