Skip to content
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

Open
wants to merge 11 commits into
base: main
Choose a base branch
from

Conversation

daniellewhyte
Copy link

@daniellewhyte daniellewhyte commented Nov 5, 2024

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 the SingleSelect and MultiSelect 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:

@daniellewhyte daniellewhyte self-assigned this Nov 5, 2024
Copy link

changeset-bot bot commented Nov 5, 2024

🦋 Changeset detected

Latest commit: 1409fab

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 2 packages
Name Type
@khanacademy/wonder-blocks-dropdown Minor
@khanacademy/wonder-blocks-birthday-picker Patch

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

Copy link
Contributor

github-actions bot commented Nov 5, 2024

Size Change: +71 B (+0.07%)

Total Size: 101 kB

Filename Size Change
packages/wonder-blocks-dropdown/dist/es/index.js 18.4 kB +71 B (+0.39%)
ℹ️ View Unchanged
Filename Size
packages/wonder-blocks-accordion/dist/es/index.js 3.78 kB
packages/wonder-blocks-banner/dist/es/index.js 1.53 kB
packages/wonder-blocks-birthday-picker/dist/es/index.js 1.77 kB
packages/wonder-blocks-breadcrumbs/dist/es/index.js 887 B
packages/wonder-blocks-button/dist/es/index.js 4.04 kB
packages/wonder-blocks-cell/dist/es/index.js 2.01 kB
packages/wonder-blocks-clickable/dist/es/index.js 3.06 kB
packages/wonder-blocks-core/dist/es/index.js 3.44 kB
packages/wonder-blocks-data/dist/es/index.js 6.24 kB
packages/wonder-blocks-form/dist/es/index.js 6.28 kB
packages/wonder-blocks-grid/dist/es/index.js 1.36 kB
packages/wonder-blocks-i18n/dist/es/index.js 4.76 kB
packages/wonder-blocks-icon-button/dist/es/index.js 3 kB
packages/wonder-blocks-icon/dist/es/index.js 871 B
packages/wonder-blocks-labeled-field/dist/es/index.js 72 B
packages/wonder-blocks-layout/dist/es/index.js 1.82 kB
packages/wonder-blocks-link/dist/es/index.js 2.28 kB
packages/wonder-blocks-modal/dist/es/index.js 5.37 kB
packages/wonder-blocks-pill/dist/es/index.js 1.65 kB
packages/wonder-blocks-popover/dist/es/index.js 4.87 kB
packages/wonder-blocks-progress-spinner/dist/es/index.js 1.52 kB
packages/wonder-blocks-search-field/dist/es/index.js 1.3 kB
packages/wonder-blocks-switch/dist/es/index.js 1.94 kB
packages/wonder-blocks-testing-core/dist/es/index.js 3.74 kB
packages/wonder-blocks-testing/dist/es/index.js 1.07 kB
packages/wonder-blocks-theming/dist/es/index.js 693 B
packages/wonder-blocks-timing/dist/es/index.js 1.8 kB
packages/wonder-blocks-tokens/dist/es/index.js 2.36 kB
packages/wonder-blocks-toolbar/dist/es/index.js 905 B
packages/wonder-blocks-tooltip/dist/es/index.js 7.08 kB
packages/wonder-blocks-typography/dist/es/index.js 1.23 kB

compressed-size-action

Copy link
Contributor

github-actions bot commented Nov 5, 2024

A new build was pushed to Chromatic! 🚀

https://5e1bf4b385e3fb0020b7073c-nbpljwnegk.chromatic.com/

Chromatic results:

Metric Total
Captured snapshots 372
Tests with visual changes 2
Total stories 506
Inherited (not captured) snapshots [TurboSnap] 0
Tests on the build 372

@daniellewhyte daniellewhyte changed the title Use Node as label in SingleSelect and MultiSelect [WIP] Update label in SingleSelect and MultiSelect Nov 5, 2024
@daniellewhyte daniellewhyte marked this pull request as ready for review November 5, 2024 23:53
@khan-actions-bot khan-actions-bot requested a review from a team November 5, 2024 23:54
@khan-actions-bot
Copy link
Contributor

khan-actions-bot commented Nov 5, 2024

Gerald

Required Reviewers
  • @Khan/wonder-blocks for changes to .changeset/thirty-shirts-leave.md, __docs__/wonder-blocks-dropdown/multi-select.argtypes.ts, __docs__/wonder-blocks-dropdown/multi-select.stories.tsx, __docs__/wonder-blocks-dropdown/option-item-examples.tsx, __docs__/wonder-blocks-dropdown/single-select.argtypes.ts, __docs__/wonder-blocks-dropdown/single-select.stories.tsx, packages/wonder-blocks-dropdown/src/components/multi-select.tsx, packages/wonder-blocks-dropdown/src/components/single-select.tsx, packages/wonder-blocks-dropdown/src/util/helpers.ts, packages/wonder-blocks-dropdown/src/components/__tests__/multi-select.test.tsx, packages/wonder-blocks-dropdown/src/components/__tests__/single-select.test.tsx, packages/wonder-blocks-dropdown/src/util/__tests__/helpers.test.tsx

Don't want to be involved in this pull request? Comment #removeme and we won't notify you of further changes.

Copy link
Contributor

github-actions bot commented Nov 5, 2024

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

@daniellewhyte daniellewhyte changed the title [WIP] Update label in SingleSelect and MultiSelect Update label in SingleSelect and MultiSelect Nov 8, 2024
@daniellewhyte
Copy link
Author

@Khan/wonder-blocks This is now ready for review.

Copy link
Member

@marcysutton marcysutton left a 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 = {
Copy link
Member

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?

Copy link
Author

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 = {
Copy link
Member

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",
Copy link
Member

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.

Copy link
Member

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!

const defaultLabels: Labels = {
...builtinLabels,
selectAllLabel: (numOptions: any) => `Select all (${numOptions})`,
noneSelected: "Choose",
someSelected: (numSelectedValues: any) =>
numSelectedValues > 1 ? `${numSelectedValues} students` : "1 student",
allSelected: "All students",
};

Copy link
Member

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>
Copy link
Member

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.

@khan-actions-bot khan-actions-bot requested a review from a team November 12, 2024 17:06
Copy link
Member

@beaesguerra beaesguerra left a 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",
Copy link
Member

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!

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
Copy link
Member

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!

Copy link
Author

@daniellewhyte daniellewhyte Nov 12, 2024

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.

Copy link
Author

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.
Screenshot 2024-11-13 at 9 07 33 AM

That said, my specific use case does not use filtering.

Copy link
Member

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!

Copy link
Member

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.

Copy link
Member

@jandrade jandrade left a 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",
Copy link
Member

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
Copy link
Member

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.

@daniellewhyte
Copy link
Author

@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

@daniellewhyte daniellewhyte reopened this Nov 26, 2024
@daniellewhyte
Copy link
Author

Reopened PR using an approached suggested by Bea when we huddled a while back. Some context here: https://khanacademy.slack.com/archives/C4PE1QM5Y/p1732564950057359

Copy link
Member

@beaesguerra beaesguerra left a 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;
Copy link
Member

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,
Copy link
Member

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!

@@ -0,0 +1,5 @@
---
"@khanacademy/wonder-blocks-dropdown": patch
Copy link
Member

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!

Suggested change
"@khanacademy/wonder-blocks-dropdown": patch
"@khanacademy/wonder-blocks-dropdown": minor

Copy link
Member

@beaesguerra beaesguerra left a 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 🎉 🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants