Skip to content

Add Textarea component - #1812

Merged
rezrah merged 19 commits into
mainfrom
feature/add-textarea-form-component
Feb 1, 2022
Merged

Add Textarea component#1812
rezrah merged 19 commits into
mainfrom
feature/add-textarea-form-component

Conversation

@rezrah

@rezrahrezrah commented Jan 20, 2022

Copy link
Copy Markdown
Contributor

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 colebemisJanuary 20, 2022 15:13
@changeset-bot

changeset-botBot commented Jan 20, 2022

Copy link
Copy Markdown

🦋 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
NameType
@primer/reactMinor

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

github-actionsBot commented Jan 20, 2022

Copy link
Copy Markdown
Contributor

size-limit report 📦

PathSize
dist/browser.esm.js61.64 KB (+0.49% 🔺)
dist/browser.umd.js62 KB (+0.46% 🔺)

Comment threadsrc/TextArea.tsx Outdated
Comment threadsrc/TextArea.tsx Outdated
Comment threadsrc/TextArea.tsx Outdated
SxProp

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

Copy link
Copy Markdown
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
Copy Markdown
ContributorAuthor

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
Copy Markdown
ContributorAuthor

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
Copy Markdown
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.

Comment threadsrc/TextArea.tsx Outdated
Comment threadsrc/TextArea.tsx Outdated
} & TextareaHTMLAttributes<HTMLTextAreaElement> &
SxProp

const StyledTextArea = styled.textarea<TextAreaProps>`

Copy link
Copy Markdown
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
Copy Markdown
ContributorAuthor

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
Copy Markdown
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 propUsed for TextArea?
disabled
hasLeadingVisual
hasTrailingVisual
block
contrast
validationStatus
size

Copy link
Copy Markdown
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.

Comment threadsrc/__tests__/__snapshots__/TextArea.test.tsx.snap
Comment threaddocs/content/TextArea.mdx Outdated
Comment threaddocs/content/TextArea.mdx Outdated
Comment threaddocs/content/TextArea.mdx Outdated
Comment threaddocs/content/TextArea.mdx Outdated
Comment threaddocs/content/TextArea.mdx Outdated
Comment threaddocs/content/TextArea.mdx Outdated
Comment threadsrc/TextArea.tsx Outdated
Comment threadsrc/TextArea.tsx Outdated
Comment threaddocs/content/TextArea.mdx Outdated
description="Indicates to the user and assistive technologies that the field value is required"
/>
<PropsTableRow
name="block"

Copy link
Copy Markdown
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
Copy Markdown
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
Copy Markdown
ContributorAuthor

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
Copy Markdown
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
Copy Markdown
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.

Comment threaddocs/content/TextArea.mdx
Comment threaddocs/content/TextArea.mdx Outdated
Comment threaddocs/content/TextArea.mdx Outdated
Comment threaddocs/content/TextArea.mdx
Comment threaddocs/content/TextArea.mdx

@mperrottimperrotti left a comment

Copy link
Copy Markdown
Contributor

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.

Comment threadsrc/TextArea.tsx Outdated
} & TextareaHTMLAttributes<HTMLTextAreaElement> &
SxProp

const StyledTextArea = styled.textarea<TextAreaProps>`

Copy link
Copy Markdown
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
Copy Markdown
ContributorAuthor

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
Copy Markdown
ContributorAuthor

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 mperrottiJanuary 31, 2022 14:09

@mperrottimperrotti left a comment

Copy link
Copy Markdown
Contributor

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! 🎉

Comment threadsrc/TextArea.tsx Outdated
Comment threadsrc/TextArea.tsx
@colebemis

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

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

@rezrah

Copy link
Copy Markdown
ContributorAuthor

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

@rezrahrezrah changed the title Add TextArea componentAdd Textarea componentFeb 1, 2022
@rezrah
rezrah merged commit 97bf7c6 into mainFeb 1, 2022
@rezrah
rezrah deleted the feature/add-textarea-form-component branch February 1, 2022 15:11
@primer-cssprimer-css mentioned this pull request Feb 1, 2022
Sign up for freeto 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

@rezrah@colebemis@mperrotti@siddharthkp@alliethu