-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
MenuItemsChoice
: Refactor to TypeScript
#47180
Conversation
Size Change: +9 B (0%) Total Size: 1.31 MB
ℹ️ View Unchanged
|
78431eb
to
62c3b47
Compare
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.
Thank you for helping out with the TS migrations! I appreciate you adding a Storybook story so we can see what's going on.
We'll also need a brief changelog entry, thanks 🙏
/** | ||
* Array of choices | ||
*/ | ||
choices: readonly MenuItemChoice[]; |
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.
Interesting! I've never really considered using readonly
like this because it's a given that a React component won't mutate its props, but I guess it adds another layer of protection. Just curious, have you ever encountered situations where a component was inadvertently mutating a prop?
cc @ciampo
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.
Never personally seen anything like it, off the top of my mind. But curiously enough, I encountered recently readonly
in the QueryControls
typescript refactor PR: #46721
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.
To be honest this is a copy paste. I'll let you decide whether that's something we want to keep.
I've definitely seen code which reassigns and/or mutates props but it's not exactly considered a good practice and is usually avoided. As you mentioned I'd consider readonly
an additional layer of protection which warns you when you're trying to e.g. .push
something to the choices
array instead of creating a new array and spread the existing array.
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 mean, it certainly doesn't hurt! I looked into it and some people actually suggest doing readonly
by default on all arrays 😆 I will keep it in mind as well.
} | ||
} } | ||
onMouseEnter={ () => onHover( item.value ) } | ||
onMouseLeave={ () => onHover() } |
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.
Any reason why this was changed from () => onHover( null )
? This could be a breaking change for a consumer that was specifically doing null
checks, so I think we should avoid the change if possible.
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 we need to keep the API to make sure we don't introduce a breaking change at this point. There's no particular reason other than me finding this kind of an odd API to return explicitly null
in case no element is hovered. Reverted via 9baa7fb.
62c3b47
to
9baa7fb
Compare
Flaky tests detected in eff0379. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/4113137924
|
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! The JSDoc placement needs to be tweaked, but otherwise this looks ready to merge 🚀
/** | ||
* Array of choices | ||
*/ | ||
choices: readonly MenuItemChoice[]; |
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 mean, it certainly doesn't hurt! I looked into it and some people actually suggest doing readonly
by default on all arrays 😆 I will keep it in mind as well.
c727398
to
856a1ba
Compare
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.
Left a couple of minor comments about missing @default
tags in the JSDoc descriptions.
I also noticed that this component doesn't list any of its props in the README, which means that we don't really have to amend that as part of this PR, if we want to speed up the TS refactor
2683aa2
to
6574991
Compare
This is necessary so it's shown on the documentation page of the Storybook entry.
Co-authored-by: Marco Ciampini <marco.ciampo@gmail.com>
6574991
to
eff0379
Compare
What?
Refactor
MenuItemsChoice
component to TypeScriptWhy?
Part of #35744
How?
.tsx
and created atypes.ts
file with relevant typesTesting Instructions
Wit this PR we introduce a story for this component. Please verify it behaves as expected.