chore(ButtonGroup): 🤖 add forwardRef

[punkbit]

Why?

All components in a library should behave similarly, e.g. if Button forwards refs, ButtonGroup should too. For this reason, added forwardRef to the component ButtonGroup. With forwardRef, parent components can access the underlying DOM node for any purpose they need.

How?

• Wrap ButtonGroup into forwardRef

Tickets?

N/A

Contribution checklist?

• You've done enough research before writing
• You have reviewed the PR
• The commit messages are detailed
• The build command runs locally
• Assets or static content are linked and stored in the project
• For documentation, guides or references, you've tested the commands

Preview?

N/A

[changeset-bot]

🦋 Changeset detected

Latest commit: a895831

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@clickhouse/click-ui	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions]

Claude finished @punkbit's task in 1m 12s —— View job

---

PR Review

• Gather context and read changed files
• Review conventions and guidelines
• Analyze changes for bugs, API correctness, types, a11y, and tests
• Post final review

---

✅ Looks great! This is a clean, well-scoped change — nice work!

The forwardRef wiring is correct end-to-end:

• forwardRef<HTMLDivElement, ButtonGroupProps> matches the root element type (ButtonGroupWrapper renders a div) and the existing public props interface
• ref is correctly placed before {...props} on ButtonGroupWrapper, with the critical accessibility attribute role="group" still pinned after the spread so it can't be overridden by callers
• displayName = 'ButtonGroup' is set — important for DevTools readability when components are wrapped in HOCs like forwardRef
• The hoisted ButtonGroupType import from the bottom of the old file is now properly consolidated at the top — good cleanup
• Test directly asserts ref.current instanceof HTMLDivElement, which is the right way to verify the target DOM node

💡 Suggestion (non-blocking)

• ButtonGroup.test.tsx: Consider also asserting that ref.current is not null before the instanceof check, or use .not.toBeNull() as a first assertion. Both checks together make failure messages more precise if the ref is never populated vs. pointing to the wrong element type. That said, vitest's toBeInstanceOf already fails meaningfully, so this is purely stylistic.

[workflow-authentication-public]

📚 Storybook Preview Deployed

✅ Preview URL: https://click-dpnx5gao1-clickhouse.vercel.app

Built from commit: 8441abfbda32267ffb99fcc55a3119a72b75b803