Skip to content

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

Merged
merged 19 commits into from
Feb 1, 2022
Merged

Add Textarea component #1812

merged 19 commits into from
Feb 1, 2022

Conversation

rezrah
Copy link
Contributor

@rezrah rezrah commented Jan 20, 2022

Adds a Textarea component.

Try it here: Docs | Storybook

Screenshots

Docs

Merge checklist

  • Added/updated tests
  • Added/updated documentation
  • Tested in Chrome
  • Tested in Firefox
  • Tested in Safari
  • Tested in Edge

@rezrah rezrah requested review from a team and colebemis January 20, 2022 15:13
@changeset-bot
Copy link

changeset-bot bot commented Jan 20, 2022

🦋 Changeset detected

Latest commit: 06acbaf

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

This PR includes changesets to release 1 package
Name Type
@primer/react Minor

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

@github-actions
Copy link
Contributor

github-actions bot commented Jan 20, 2022

size-limit report 📦

Path Size
dist/browser.esm.js 61.64 KB (+0.49% 🔺)
dist/browser.umd.js 62 KB (+0.46% 🔺)

src/TextArea.tsx Outdated
SxProp

const StyledTextArea = styled.textarea<TextAreaProps>`
min-height: 124px;
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor Author

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?

Copy link
Contributor

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>`
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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

Copy link
Contributor

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.

description="Indicates to the user and assistive technologies that the field value is required"
/>
<PropsTableRow
name="block"
Copy link
Contributor

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

Copy link
Contributor

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

Copy link
Contributor Author

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?

Copy link
Contributor

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?

Copy link
Contributor

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.

Copy link
Contributor

@mperrotti mperrotti left a 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>`
Copy link
Contributor

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>`
Copy link
Contributor Author

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
Copy link
Contributor Author

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.

@rezrah rezrah requested a review from mperrotti January 31, 2022 14:09
Copy link
Contributor

@mperrotti mperrotti left a 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! 🎉

@colebemis
Copy link
Contributor

My strong opinion weakly held is that we should call this component Textarea instead of TextArea. Since this component is a simple wrapper around the HTML <textarea> element, <Textarea> seems more intuitive than <TextArea>.

@mperrotti
Copy link
Contributor

FWIW, I also prefer Textarea, but it's also my strong opinion weakly held

@rezrah
Copy link
Contributor Author

rezrah commented Feb 1, 2022

@mperrotti @colebemis FYI, I've renamed everything to Textarea. Seems there's ecosystem alignment for this too, so happy to make that change.

@rezrah rezrah changed the title Add TextArea component Add Textarea component Feb 1, 2022
@rezrah rezrah merged commit 97bf7c6 into main Feb 1, 2022
@rezrah rezrah deleted the feature/add-textarea-form-component branch February 1, 2022 15:11
@primer-css primer-css mentioned this pull request Feb 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants