feat(ui5-table-row): add semantic click event on TableRow

[pskelin]

Summary

• ui5-table-row now fires its own custom click event when an interactive row is activated via mouse click or Enter key
• The native DOM click is intercepted in the constructor (like Button) and replaced with a CustomEvent that unifies mouse and keyboard activation
• The existing Table-level row-click event is preserved for backward compatibility
• Follows the established semantic click pattern used by Button, Link, Icon, CardHeader, and other components

This enables React consumers using createReactComponent to attach onClick handlers directly on <TableRow>:

<TableRow interactive={true} onClick={() => handleRowClick()}>

Implementation details

• @eventStrict("click", { bubbles: true }) declared on TableRow
• eventDetails.click declared on TableRowBase to maintain JSX type compatibility across the hierarchy (same pattern as SideNavigationItemBase)
• Native click suppressed via stopImmediatePropagation in a constructor-registered listener, then forwarded to the Table's event router so TableNavigation and other extensions still work
• _handleClick() fires fireDecoratorEvent("click") followed by _table._onRowClick() for backward compat

Test plan

• New test: "fires click event on the row element" — verifies non-interactive rows don't fire, interactive rows fire CustomEvent on click and Enter
• Existing row-click test still passes
• Selection tests (TableSelections.cy.tsx) all pass — RowOnly behavior unaffected
• TypeScript compiles cleanly
• New RowClick sample renders correctly on the documentation website

[ui5-webcomponents-bot]

🚀 Deployed on https://pr-13303--ui5-webcomponents-preview.netlify.app

[aborjinik]

-2

Sorry Petar, this doesn’t make sense to me. TableRow is not an atomic component like Button, Link, or Icon. It can contain interactive elements inside. We should not change the meaning of the native click event just to provide convenience for a group of consumers, regardless of its size.

Also, a component should never stop the (immediate) propagation of an event without fully handling it especially when we don't know how it's being used.

Overall, I'm against this approach. It would also be incompatible if someone is already using the row’s click event. But I'm fine with introducing a separate event (e.g. press or rowClick) that represents this behavior. The main issue is changing the meaning of click and stopping the propagation.

[aborjinik]

That is not even true.