-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update label in SingleSelect and MultiSelect #2354
base: main
Are you sure you want to change the base?
Conversation
🦋 Changeset detectedLatest commit: 1409fab The changes in this PR will be included in the next version bump. This PR includes changesets to release 2 packages
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 |
Size Change: +71 B (+0.07%) Total Size: 101 kB
ℹ️ View Unchanged
|
A new build was pushed to Chromatic! 🚀https://5e1bf4b385e3fb0020b7073c-nbpljwnegk.chromatic.com/ Chromatic results:
|
GeraldRequired Reviewers
Don't want to be involved in this pull request? Comment |
npm Snapshot: Published🎉 Good news!! We've packaged up the latest commit from this PR (c4f542e) and published all packages with changesets to npm. You can install the packages in webapp by running: ./services/static/dev/tools/deploy_wonder_blocks.js --tag="PR2354" Packages can also be installed manually by running: yarn add @khanacademy/wonder-blocks-<package-name>@PR2354 |
@Khan/wonder-blocks This is now ready for review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is looking solid to me but I'd be curious to hear what @jandrade and @beaesguerra have to say. These components are pretty complex!
Great job, @daniellewhyte!
* one option is selected and `labelAsText` is undefined. | ||
* **Note** this is only supported for SingleSelect and MultiSelect, not Combobox. | ||
*/ | ||
export const CustomOptionItemsWithoutTextLabel: StoryComponentType = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it's just me, but I found the "without text label" part of these new stories a little confusing! 😅
Would something like "with node label" or "with child element as label" reflect the unique aspect of these updates?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, good suggestion! just pushed an update
* `labelAsText` is undefined. | ||
* **Note** this is only supported for SingleSelect and MultiSelect, not Combobox. | ||
*/ | ||
export const CustomOptionItemWithoutTextLabel: StoryComponentType = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as above. Would renaming these stories with something like "With element child as label" work for you? It would make it easier to understand them when scanning through Storybook.
@@ -150,7 +150,7 @@ describe("MultiSelect", () => { | |||
|
|||
// Assert | |||
expect(await screen.findByRole("button")).toHaveTextContent( | |||
"1 student", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wow, that's a pretty confusing test result looking at this older code. Where did "student" even come from? Your change seems way more intuitive.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was wondering the same thing! Looks like "1 student" was coming from the defaultLabels
that are passed in!
wonder-blocks/packages/wonder-blocks-dropdown/src/components/__tests__/multi-select.test.tsx
Lines 28 to 35 in 5eedd04
const defaultLabels: Labels = { | |
...builtinLabels, | |
selectAllLabel: (numOptions: any) => `Select all (${numOptions})`, | |
noneSelected: "Choose", | |
someSelected: (numSelectedValues: any) => | |
numSelectedValues > 1 ? `${numSelectedValues} students` : "1 student", | |
allSelected: "All students", | |
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bea's assumption is correct. This is part of what Danielle fixed with this PR. Previously, we used the label associated for that, but from now on we'll be using whatever it is passed in as a custom option item label. This means that if we don't use a custom label, then someSelected(1)
should be used in this case. @daniellewhyte I'm not sure if there's an existing unit test for this case, but if not, it would be good adding one here to prevent possible regressions in the future.
value={String(index)} | ||
horizontalRule="full-width" | ||
label={ | ||
<span> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This tested well in VoiceOver! I couldn't get my Windows VM to load the local Storybook environment for NVDA but I'm pretty sure it will be fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for looking into this, @daniellewhyte 😄
I noticed a bug when we set isFilterable
in the CustomOptionItemsWithNodeLabel
story and had follow up questions!
@@ -150,7 +150,7 @@ describe("MultiSelect", () => { | |||
|
|||
// Assert | |||
expect(await screen.findByRole("button")).toHaveTextContent( | |||
"1 student", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was wondering the same thing! Looks like "1 student" was coming from the defaultLabels
that are passed in!
wonder-blocks/packages/wonder-blocks-dropdown/src/components/__tests__/multi-select.test.tsx
Lines 28 to 35 in 5eedd04
const defaultLabels: Labels = { | |
...builtinLabels, | |
selectAllLabel: (numOptions: any) => `Select all (${numOptions})`, | |
noneSelected: "Choose", | |
someSelected: (numSelectedValues: any) => | |
numSelectedValues > 1 ? `${numSelectedValues} students` : "1 student", | |
allSelected: "All students", | |
}; |
}; | ||
|
||
return ( | ||
<MultiSelect |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I played around with the changes and found if we set isFilterable
in this story, the filtering functionality doesn't work as expected! However, if we add a labelAsText
prop to the OptionItem
components with the content (ie. the locale
in this example), filtering works as expected.
I'm wondering, should we use labelAsText
prop when we use a node label? And if so, would that solve for the original issue where the select opener is labeled with an empty string? Let me know though if there's some context I'm missing!
cc: @jandrade , I think he was running into similar things when he worked on the combobox!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good callout, and the proposed solution does solve the original issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@beaesguerra Actually I don't think this works. If you add labelAsText
to the option item, you see plain text as the label for the menu.
That said, my specific use case does not use filtering.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah I see, we want to include the icon in the field! Thanks for trying that out!
For other use cases that would need filtering, the labelAsText
prop would fix the filtering issue (with the drawback that the menu opener would show the labelAsText
instead of the custom option). With that said, the changes look good to me, though I would also like to get @jandrade's thoughts since he has more context around this!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand that the specific use case in this PR doesn't need filtering, but I worry that adding this feature while introducing a known issue might be counterproductive if there's another call site that needs both things (custom options + filtering).
I'd really recommend applying the fix/change in this PR before landing this change.
I was thinking that it might be solved by changing the filter logic to use .toString()
after the getSelectOpenerLabel
invocation. I'm not fully sure if this is the right solution but it might be worth trying it out for both MultiSelect
and SingleSelect
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is looking great, thanks! I'm requesting changes to include the new helper in the filtering feature to prevent regressions in the future.
Let me know if you have more questions, happy to pair and chat about it.
@@ -150,7 +150,7 @@ describe("MultiSelect", () => { | |||
|
|||
// Assert | |||
expect(await screen.findByRole("button")).toHaveTextContent( | |||
"1 student", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bea's assumption is correct. This is part of what Danielle fixed with this PR. Previously, we used the label associated for that, but from now on we'll be using whatever it is passed in as a custom option item label. This means that if we don't use a custom label, then someSelected(1)
should be used in this case. @daniellewhyte I'm not sure if there's an existing unit test for this case, but if not, it would be good adding one here to prevent possible regressions in the future.
}; | ||
|
||
return ( | ||
<MultiSelect |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand that the specific use case in this PR doesn't need filtering, but I worry that adding this feature while introducing a known issue might be counterproductive if there's another call site that needs both things (custom options + filtering).
I'd really recommend applying the fix/change in this PR before landing this change.
I was thinking that it might be solved by changing the filter logic to use .toString()
after the getSelectOpenerLabel
invocation. I'm not fully sure if this is the right solution but it might be worth trying it out for both MultiSelect
and SingleSelect
.
@Khan/wonder-blocks I'm going to go ahead and close this. For anyone who stumbles upon this in the future, context is here: https://khanacademy.slack.com/archives/C4PE1QM5Y/p1731532324639189 |
Reopened PR using an approached suggested by Bea when we huddled a while back. Some context here: https://khanacademy.slack.com/archives/C4PE1QM5Y/p1732564950057359 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is working great, thanks for the fix 🎉 custom node is shown for the selected value and filtering works as expected with the option labelAsText
prop 😄
Left a few minor comments around naming and versioning!
* plain text label can be provided with the `labelAsText` prop. | ||
* Defaults to true. | ||
*/ | ||
showLabelAsText: boolean; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
super minor: What do you think about naming the prop showOpenerLabelAsText
so it helps communicate that it's used for the opener? (same for SingleSelect!)
@@ -227,6 +234,7 @@ export default class MultiSelect extends React.Component<Props, State> { | |||
light: false, | |||
shortcuts: false, | |||
selectedValues: [], | |||
showLabelAsText: true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 Great idea defaulting to true for existing usage!
.changeset/thirty-shirts-leave.md
Outdated
@@ -0,0 +1,5 @@ | |||
--- | |||
"@khanacademy/wonder-blocks-dropdown": patch |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will be a minor
update since a new prop was added!
"@khanacademy/wonder-blocks-dropdown": patch | |
"@khanacademy/wonder-blocks-dropdown": minor |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great! Thanks for working on this improvement 🎉 🚀
Summary:
When you pass in a JSX Element as a label to
OptionItem
, the SelectOpener is labeled with an empty string. This PR updates SelectOpener in theSingleSelect
andMultiSelect
components to return the JSX as a label in that case.This change is being made to unblock supporting TEX in the Perseus Dropdown widget.
Issue: LIT-1425
Test plan: