feat(select): flexibility in dropdown menu width#1744
Conversation
|
|
🚀 Deployed on https://pr-1744--dhis2-ui.netlify.app |
tomzemp
left a comment
tomzemp
left a comment
There was a problem hiding this comment.
Looks good to me! 🎉 (I've read through the code and tested in the aggregate data entry app).
Are we going to extend this to SimpleSingleSelect component as well? (The docs say we're planning on deprecating SingleSelect (https://github.com/dhis2/ui/blob/master/docs/docs/components/select.md?plain=1#L41) though I don't know if we've ever moved forward with that, but we seem to be using both in our apps.
We might also want to add some notes in the select documentation for this (above the notes generated from the props) to explain the behaviour.
| loading: PropTypes.bool, | ||
| loadingText: PropTypes.string, | ||
| maxHeight: PropTypes.string, | ||
| /** Sets a maximum width for the dropdown menu */ |
There was a problem hiding this comment.
these need to be defined as 'px', right? I tried for example percentages, and they did not work. If the idea is that we just use 'px', it might be good to update the description here (as it flows through into documentation for component)
There was a problem hiding this comment.
That's a good point. Thanks!
I updated the select documentation with the new behavior explanation and added links in the props description. Left a note about avoiding percentages too.
| const flexible = menuMinWidth || menuMaxWidth | ||
| const width = flexible ? 'fit-content' : inputWidth | ||
| const flexibleMinWidth = menuMinWidth | ||
| ? `max(${inputWidth}, ${menuMinWidth})` |
There was a problem hiding this comment.
just curious: are we using the css calc definition here to avoid issues with taking the max() ourselves and just passing the resulting number?
There was a problem hiding this comment.
Yes, that’s correct, and to ensure consistent behavior in the affected components.
… and SingleSelect components Co-authored-by: Cursor <cursoragent@cursor.com>
|
Created LIBS-869 |
kabaros
left a comment
kabaros
left a comment
There was a problem hiding this comment.
it looks great @arina-gutuboe - just adding to Tom's point, would you be able to add the behaviour to SimpleSelect too? The "Simple" varieties make these components accessible and are the receommended way going forward - The SingleSelect is marked for deprecation: https://developers.dhis2.org/docs/ui/components/select#single-select .. we're just doing it gradually since it's used in a lot of places and there was no way to make the changes backwards compatible (I can give you more context if you'd like)
it would be good to add the same functionality to SimpleSingleSelect before merging - happy to help with that
Sorry @arina-gutuboe , I didn't notice your comment about the linked ticket. I will merge this one, and you can catch up with the other ticket after. |
# [10.17.0](v10.16.5...v10.17.0) (2026-07-20) ### Features * **select:** flexibility in dropdown menu width ([#1744](#1744)) ([b721f9d](b721f9d))
4 participants
Implements LIBS-837
Description
SingleSelectandMultiSelectmeasure the input width and pass it to the dropdown as a fixed pixel width. That works for a wide input, but breaks when the input becomes too narrow: long labels get compressed in the menu, and the result looks unnecessarily tight.This PR adds two optional props —
menuMinWidthandmenuMaxWidth— onSingleSelect,MultiSelect,SingleSelectField, andMultiSelectField. They are forwarded through the sharedSelect/MenuWrapperstack.Known issues
With only
menuMinWidth(nomenuMaxWidth), the menu can grow without an upper bound for very long option labels;menuMinWidthandmenuMaxWidthshould be used together when labels can vary significantly in length.Checklist
Screenshots
menuMaxWidthis slightly greater than the width of the input, but less than the width of the options:with
menuMinWidth: