-
Notifications
You must be signed in to change notification settings - Fork 616
Add Textarea component #1812
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
Add Textarea component #1812
Conversation
🦋 Changeset detectedLatest commit: 06acbaf The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
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-limit report 📦
|
src/TextArea.tsx
Outdated
SxProp | ||
|
||
const StyledTextArea = styled.textarea<TextAreaProps>` | ||
min-height: 124px; |
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.
Where does "124px" come from?
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.
It's the height that's set on the text area component in Figma. Took it from there.
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've now removed this min-height, so the user is forced to set their own. Was the textarea in Figma just an example, or intentional min-height @mperrotti?
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.
If we end up using rows
instead of height
, I'd set the a default value for rows instead of specifying a min-height.
Otherwise, just make sure 124px perfectly fits {n} lines of text and doesn't cut off any lines of text in their vertical middle.
src/TextArea.tsx
Outdated
} & TextareaHTMLAttributes<HTMLTextAreaElement> & | ||
SxProp | ||
|
||
const StyledTextArea = styled.textarea<TextAreaProps>` |
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.
The Select and TextInput component both just use the private TextInputWrapper
component to maintain consistent styling. I'd recommend we do that here too.
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 did think about this, and decided against it as that component had styling that wasn't relevant for this component, like warning state, size variants etc. Do we want to inherit those here? It feels like we'd be creating a dependency here for the sake of convenience, but potentially more detrimental to the user as we're loading unnecessary css and subsequently delivering a less performant component.
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.
You're right - the size variants aren't relevant. Most of the others are though:
Styling prop | Used for TextArea? |
---|---|
disabled | ✅ |
hasLeadingVisual | ❌ |
hasTrailingVisual | ❌ |
block | ✅ |
contrast | ✅ |
validationStatus | ✅ |
size | ❌ |
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 still think we should DRY this by using TextInputWrapper
or something that replaces it. It's unlikely somebody is going to load the CSS for a TextArea
and not also have a component on the page that loads TextInputWrapper
styles (e.g.: TextInput
or Select
). Then, we'd downloading nearly identical styles twice.
docs/content/TextArea.mdx
Outdated
description="Indicates to the user and assistive technologies that the field value is required" | ||
/> | ||
<PropsTableRow | ||
name="block" |
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 wonder if we should remove the block
prop in favor of sx={{width: '100%'}}
(in both TextArea and TextInput) cc @mperrotti
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'd be down with that if that's all block
is doing
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.
Feels like a very common use-case. Are we over-relying on sx
here to handle scenarios many users would expect to be done via props?
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'm okay with a prop for this use case if we think it's pretty common. I'm not the biggest fan of block
as a name for this though. What do y'all think?
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 agree that block
is a little unclear, but I'd prefer we change the naming for all components that use block
if we choose to make it different here.
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.
Everything is looking good, there's just that one styling sugggestion.
src/TextArea.tsx
Outdated
} & TextareaHTMLAttributes<HTMLTextAreaElement> & | ||
SxProp | ||
|
||
const StyledTextArea = styled.textarea<TextAreaProps>` |
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 still think we should DRY this by using TextInputWrapper
or something that replaces it. It's unlikely somebody is going to load the CSS for a TextArea
and not also have a component on the page that loads TextInputWrapper
styles (e.g.: TextInput
or Select
). Then, we'd downloading nearly identical styles twice.
const textInputBasePadding = '12px' | ||
export const textInputHorizPadding = textInputBasePadding | ||
|
||
export const TextInputBaseWrapper = styled.span<StyledBaseWrapperProps>` |
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.
In order to reuse TextInputWrapper
, I've abstracted the base styles into TextInputBaseWrapper
, which apply universally to all types of text input, including textarea.
@@ -1 +1 @@ | |||
export type FormValidationStatus = 'error' | 'success' | |||
export type FormValidationStatus = 'error' | 'success' | 'warning' // TODO: remove warning as a breaking change. Added for backwards compatibility with TextArea |
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.
Not ideal, but this avoids a breaking change to TextInput by leaving warning
in play. I'd recommend we use the upcoming form validation work to remove warning
altogether and defer the breaking change.
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.
Two small comments about styling, but otherwise LGTM! 🎉
My strong opinion weakly held is that we should call this component |
FWIW, I also prefer |
@mperrotti @colebemis FYI, I've renamed everything to |
Adds a
Textarea
component.Try it here: Docs | Storybook
Screenshots
Merge checklist