Replace forwarded ref instances of useProvidedRefOrCreate with useMergedRefs

[iansan5653]

In #7638 I created a useMergedRefs hook and migrated all instances of useRefObjectAsForwardedRef to it.

A similar pattern is using useProvidedRefOrCreate for this. It's typically used with a type cast and a ts-expect-error comment (❗):

const ref = useProvidedRefOrCreate(forwardedRef as RefObject<HTMLElement | null>)

// @ts-expect-error
return <div ref={ref} />

This is obviously problematic. The type errors are trying to point out the problem with this pattern: it will break if consumers pass ref callbacks. Ref callbacks are likely to become more and more common as React 19 has introduced ref callback cleanup functions, making ref callbacks a viable alternative to effects.

A much better pattern is to be consistent and use the same approach as in #7638:

const ref = useRef<HTMLElement>(null)
const combinedRef = useCombinedRefs(ref, forwardedRef)

return <div ref={combinedRef} />

Note, however, that I did not deprecate useProvidedRefOrCreate or remove all calls to it. There are still some valid use cases where refs can be passed in to refer to elements rendered outside the component. We most often see this in anchor refs. There are also some utility hooks that can create a ref internally or use a passed ref. These two cases are still valid; the case I'm targeting here is specifically around forwarded refs.

• Stacks on Update useMergedRefs to be React 19 compatible and public + deprecate useRefObjectAsForwardedRef and useProvidedRefOrCreate #7672

Changelog

New

Changed

Removed

Rollout strategy

• Patch release
• Minor release
• Major release; if selected, include a written rollout or migration plan
• None; if selected, include a brief description as to why

Testing & Reviewing

Merge checklist

• Added/updated tests
• Added/updated documentation
• Added/updated previews (Storybook)
• Changes are SSR compatible
• Tested in Chrome
• Tested in Firefox
• Tested in Safari
• Tested in Edge
• (GitHub staff only) Integration tests pass at github/github-ui (Learn more about how to run integration tests)

[changeset-bot]

⚠️ No Changeset found

Latest commit: 7b45d61

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

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

[github-actions]

⚠️ Action required

👋 Hi, this pull request contains changes to the source code that github/github-ui depends on. If you are GitHub staff, test these changes with github/github-ui using the integration workflow. Or, apply the integration-tests: skipped manually label to skip these checks.

[primer]

🤖 Lint issues have been automatically fixed and committed to this PR.

[iansan5653]

😞 This is the most frustrating PR ever. I have no idea why the integration CI is failing, and the only way I can try things is by changing files in this PR, then waiting for the canary release, then rerunning the integration CI. So I'm going to have to revert each individual file one by one until I figure out which change is causing the failure. Very painful.

• ActionList
• AnchoredOverlay
• ButtonGroup
• Checkbox
• Dialog
• Tabs
• FilteredActionList
• useMergedRefs
• PageHeader
• TextInput
• Tooltip

[primer-integration]

⚠️ Integration PR Outdated

This integration PR does not have the latest commit from the primer/react PR.

Integration PR references: 07eeee358aba88eb1baa4c41d0f76f9b38236fce
Latest commit on primer/react PR: a120837acaf65cff30db6a33303a42e287c8d351

Please update the integration PR to reference the latest commit from the primer/react PR before reviewing workflow results.

[primer-integration]

⚠️ Hi from github/github-ui! The integration workflow could not find a canary version for the latest commit on this PR.

A successful canary CI run (i.e., a valid canary version published via the release.yml workflow) must exist for the latest commit before integration checks will succeed.

Note: Make sure the Canary Release label is applied to the PR — the release.yml workflow requires this label to publish a canary version.

Next steps:

1. Wait for the release.yml canary CI run to complete successfully for the latest commit on this PR.
2. Once a valid canary version exists, re-trigger the integration workflow by visiting the primer-react-pr-test workflow page, clicking Run workflow, and pasting this PR's URL.

For more details, see this workflow run.