chore(select): move ChangeHistory to Dropdown

[avivkeller]

Description

Ref: #7794 (comment)

This moves ChangeHistory to a more generic Dropdown component.

Validation

N/A

Related Issues

Check List

• I have read the Contributing Guidelines and made commit messages that follow the guideline.
• I have run pnpm format to ensure the code follows the style guide.
• I have run pnpm test to check if all tests are passing.
• I have run pnpm build to check if the website builds without errors.
• I've covered new added functionality with unit tests if necessary.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
nodejs-org	✅ Ready (Inspect)	Visit Preview	Jun 27, 2025 9:56pm

[Copilot]

Pull Request Overview

This PR refactors the ChangeHistory component by renaming and generalizing it into a new StatelessSelect component. The key changes are:

• The creation of a new StatelessSelect component to support generic selectable options.
• Moving the functionality from ChangeHistory into StatelessSelect.
• Removal of ChangeHistory and its associated stories and styles.

Reviewed Changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
packages/ui-components/Common/StatelessSelect/index.tsx	New generic select component with dropdown behavior.
packages/ui-components/Common/StatelessSelect/index.stories.tsx	Storybook example updated for the new StatelessSelect component.
packages/ui-components/Common/StatelessSelect/index.module.css	Removal of unused styles previously coupled with ChangeHistory.
packages/ui-components/Common/ChangeHistory/index.tsx	Removal of obsolete ChangeHistory component code.
packages/ui-components/Common/ChangeHistory/index.stories.tsx	Removal of obsolete ChangeHistory Storybook stories.

Comments suppressed due to low confidence (1)

packages/ui-components/Common/StatelessSelect/index.tsx:10

• [nitpick] The prop name 'values' might be ambiguous for representing selectable options. Consider renaming it to 'options' to better reflect its purpose.

  values: Array<HTMLProps<HTMLAnchorElement | HTMLDivElement>>;

[avivkeller]

Before merging, I'd like to get @canerakdas's approval

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 75.34%. Comparing base (6dcda98) to head (d4c341c).
Report is 1 commits behind head on main.

✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7905      +/-   ##
==========================================
+ Coverage   75.30%   75.34%   +0.03%     
==========================================
  Files         101      101              
  Lines        8326     8326              
  Branches      218      218              
==========================================
+ Hits         6270     6273       +3     
+ Misses       2054     2051       -3     
  Partials        2        2              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[ovflowd]

Can we move this under the Common/Select folder (even if as a sub-folder)

And then make a embed of the select on the current Select? So that when there's the main select hides and only the stateless remains?

[avivkeller]

And then make a embed of the select on the current Select? So that when there's the main select hides and only the stateless remains?

Huh? I'm not sure I understand what you mean?

[ovflowd]

And then make a embed of the select on the current Select? So that when there's the main select hides and only the stateless remains?

Huh? I'm not sure I understand what you mean?

The Select component or Dropdown one (idk what we call it) should embed both the JS-version of it and the Stateless version of it. So one renders on scenario and the one renders on script scenario.

It could be as asimple as:

<>
  <Dropdown className=".regDrop-{generatedId}" ... />

  <noscript>
    <style>.regDrop-{generatedId} { display: none; }</style>
    <StatelessDropdown ... />
  </noscript>
</>

[avivkeller]

The two components are structured differently. The stateful Select is implemented similarly to a <select/> element¹, while the stateless StatelessSelect² is built as a wrapper around a <details/> element.

I’d prefer to go ahead with this as-is and then open an issue to explore a stateless version of Select that mirrors its behavior more closely.

Footnotes

1. More precisely, a Radix-style imitation using divs and similar elements. ↩

2. We might consider renaming this to Dropdown, since it’s technically not a true Select. ↩

[avivkeller]

Now that I think about it, we can probably replace some of our existing selects / implementations with this, since all they do is redirect, rather than function like a Select. LanguageDropdown, for starters.

[github-actions]

Lighthouse Results

URL	Performance	Accessibility	Best Practices	SEO	Report
/en	🟢 99	🟢 100	🟢 100	🟢 91	🔗
/en/about	🟢 100	🟢 96	🟢 100	🟠 82	🔗
/en/about/previous-releases	🟢 100	🟢 96	🟢 100	🟠 83	🔗
/en/download	🟢 99	🟢 100	🟢 100	🟢 91	🔗
/en/blog	🟢 100	🟢 100	🟢 96	🟢 92	🔗

[canerakdas]

If JavaScript is available, I believe we should stick with the Radix primitive version for its accessibility features. While it's true that the props don’t fully align, the non-JavaScript fallback should still provide a functional alternative that enables users to perform basic navigation

[avivkeller]

Understood. However, can that be a follow-up?

I'd like for the generic component to land, and then someone to take on that as a separate task, since, to me, it seems vastly more complex, and I don't have the understanding of how this would work to investigate that complexity.

[avivkeller]

Or, we could also draft this PR, and anyone on the team can push to it, like a feature branch

[ovflowd]

Understood. However, can that be a follow-up?

I'd like for the generic component to land, and then someone to take on that as a separate task, since, to me, it seems vastly more complex, and I don't have the understanding of how this would work to investigate that complexity.

Possibly then, we should refrain from replacing the JavaScript one for the not one atm. I don't think the benefit of "a non JavaScript select" versus removing all the current accessibility features is a worth trade-off. The amount of people without JS-enabled is far less than the amount of people that actually, hm... Need these accessibility sheets.

[ovflowd]

Do we have progress here?

[avivkeller]

I feel like generifying the ChangeHistory (this Pr) is good to land as is, and any potential select changes can be, as I mentioned, done in a follow-up?

@ovflowd can you rescind your block?

If you disagree, feel free to draft this.

[avivkeller]

removing all the current accessibility features is a worth trade-off.

What accessibility features have been removed? I'm sure they can be re-added?

[ovflowd]

removing all the current accessibility features is a worth trade-off.

What accessibility features have been removed? I'm sure they can be re-added?

Keyboard Selection as a starter. Radix has several a11y features built-in on their components. Hence why I believe either we just generify the Select in this PR and don't update the usages, or if we update the usages, then we gotta provide the default JS one and non-JS one as fallback, I think that is a good enough trade-off.

[ovflowd]

@ovflowd can you rescind your block?

If you disagree, feel free to draft this.

I unfortunately don't feel comfortable landing as is; But if you then revert the changes that update Select's to sue the generic one, I'd be more than happy to remove the block.