InputControl: Improve type annotations and stories #40119
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
`InputControl` itself does not accept `Flex` props. Only `InputBase` does.
mirka
added
[Type] Developer Documentation
mirka
commented
Apr 6, 2022
| @@ -65,7 +66,7 @@ export function InputBase( | |||
| size = 'default', | |||
| suffix, | |||
| ...props | |||
| }: InputBaseProps, | |||
| }: InputBaseProps & FlexProps, | |||
There was a problem hiding this comment.
I believe this is the correct placement of FlexProps. See a682653
There was a problem hiding this comment.
I think that normally we have "merged" prop types in the types.ts file (similarly to how the code was before the changes in this PR).
Is the reason for this to avoid that InputControlProps inherits FlexProps from InputBaseProps ? I wonder if those FlexProps were ever passed to InputControl (in that case, removing them could be seen as a breaking change?)
There was a problem hiding this comment.
I think that normally we have "merged" prop types in the types.ts file (similarly to how the code was before the changes in this PR).
Ah ok, I'll keep the logic in the types.ts file. 53b7e08
Is the reason for this to avoid that
InputControlPropsinheritsFlexPropsfromInputBaseProps?
Correct 👍
I verified that any FlexProps passed to InputControl would have been passed through (via ...props) to an <input>, where they would have no effect. So I think we're ok.
Comment on lines
97
to
99
| onDragEnd?: ( dragProps: DragProps ) => void; | ||
| onDragStart?: ( dragProps: DragProps ) => void; | ||
| onDrag?: ( dragProps: DragProps ) => void; |
There was a problem hiding this comment.
We're lacking in documentation for the drag stuff overall 😓 I'd say it's low priority though.
There was a problem hiding this comment.
Yeah, that's not an easy one because we want to be careful to document it in a way that doesn't necessarily expose the @use-gesture/react library as a dependency, in case we want to swap it in the future.
There was a problem hiding this comment.
Currently the generated type for these props is a bit convoluted ((dragProps: Omit<FullGestureState<"drag">, "event"> & { event: unknown; }) => void), do you think it's ok to keep it as-is, or should we try to simplify it at least for the docs description?
There was a problem hiding this comment.
Honestly I don't know what that "simplified" version would be 😅 I'm fine with keeping it as is for now, because it's probably irrelevant for 99% of consumers, at least without proper documentation.
Also TIL you can override type info in the args table. Nice option to have (when it's worth the maintenance cost)!
There was a problem hiding this comment.
Agreed, let's keep it as-is and improve it later if/when necessary
Also TIL you can override type info in the args table. Nice option to have (when it's worth the maintenance cost)!
That's very useful, definitely good to know!
|
Size Change: -202 B (0%) Total Size: 1.22 MB
ℹ️ View Unchanged
|
ciampo
reviewed
Apr 7, 2022
| * If true, the label will only be visible to screen readers. | ||
| * | ||
| * @default false | ||
| */ | ||
| hideLabelFromVision?: boolean; | ||
| isFocused: boolean; |
There was a problem hiding this comment.
Should we also add docs for isFocused (including the false default value) ?
There was a problem hiding this comment.
Sure thing. Does this description look correct? 128618a
ciampo
reviewed
Apr 7, 2022
|
Thanks for the review @ciampo, feedback has been addressed ✅ |
ciampo
approved these changes
Apr 11, 2022
Comment on lines
97
to
99
| onDragEnd?: ( dragProps: DragProps ) => void; | ||
| onDragStart?: ( dragProps: DragProps ) => void; | ||
| onDrag?: ( dragProps: DragProps ) => void; |
There was a problem hiding this comment.
Agreed, let's keep it as-is and improve it later if/when necessary
Also TIL you can override type info in the args table. Nice option to have (when it's worth the maintenance cost)!
That's very useful, definitely good to know!
| * If true, the label will only be visible to screen readers. | ||
| * | ||
| * @default false | ||
| */ | ||
| hideLabelFromVision?: boolean; | ||
| isFocused: boolean; |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Part of #35665
In preparation for #39397
What?
InputControlto be auto-generated.Why?
To improve the quality and accuracy of our documentation.
How?
Testing Instructions
npm run storybook:devInputControland compare with https://wordpress.github.io/gutenberg/?path=/docs/components-experimental-inputcontrol--default