components-js icon indicating copy to clipboard operation
components-js copied to clipboard

feat(react): allow specifying multiple device kinds in MediaDeviceMenu props

Open activescott opened this issue 2 months ago • 5 comments

feat(react): allow specifying multiple device kinds in MediaDeviceMenu props

This is an update to the MediaDeviceMenu react component to allow specifying an array of device kinds instead of a single kind.

  • The menu already rendered a multi-kind menu when no kind was specified, there was just no way to specify >1 kind to render when specifying a kind. This PR leverages that same rendering.
  • This should be API-compatible. The one type change was that the existing MediaDeviceMenuProps interface which is now a type alias for the prior props interface (now renamed MediaDeviceMenuPropsSingleKind) and the new MediaDeviceMenuPropsMultiKind props interface.

We're already using this in our app, and thought we'd share with the community. If something needs adjusted for you to accept let me know!

activescott avatar Sep 15 '25 22:09 activescott

⚠️ No Changeset found

Latest commit: 5179ebbc295959f5a0587fb4a90342631c7fd2f1

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

changeset-bot[bot] avatar Sep 15 '25 22:09 changeset-bot[bot]

CLA assistant check
All committers have signed the CLA.

CLAassistant avatar Sep 15 '25 22:09 CLAassistant

I see that the api-check failed. If you can confirm (1) that you're open to this contribution and (2) how you'd like to handle that, happy to refine this to meet your needs.

activescott avatar Sep 15 '25 22:09 activescott

thanks for the PR!

This makes sense as an addition. The API check fails as the exposed type is being changed, but as you correctly stated, the new type is backwards compatible, so I don't see any issue in adding this in.

You'll have to run pnpm run api-extractor to update the API docs and commit them as part of the PR in order for the API check to succeed

lukasIO avatar Sep 22 '25 12:09 lukasIO

I'll put this on my board and get back to it soon. Should be this week. Thanks for the feedback!

activescott avatar Sep 24 '25 19:09 activescott