Skip to content
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

feat(components): Add description to base FormField component #714

Merged
merged 22 commits into from
Oct 29, 2021

Conversation

joelzwarrington
Copy link
Contributor

Motivations

FormField's do not have a way to display longer information/description outside of an error.

In this PR I've added a description, which acts similarly to the description found in checkbox

checkbox example

input text example

Changes

Added

  • Added description to FormField component (and inputs that inherit)

Changed

  • Refactored/reorganized FormField tests using Describe so it's easier to follow

Testing

  • Add description to any input which is inheriting FormField props, such as InputText, InputPassword, Select
  • Use with Multiline inputs

In Atlantis we use Github's built in pull request reviews.

Random photo of Atlantis

@netlify
Copy link

netlify bot commented Oct 4, 2021

✔️ Deploy Preview for jobber-atlantis ready!

🔨 Explore the source changes: 1ab04e9

🔍 Inspect the deploy log: https://app.netlify.com/sites/jobber-atlantis/deploys/61784d21f04387000702d6ec

😎 Browse the preview: https://deploy-preview-714--jobber-atlantis.netlify.app

@chris-at-jobber
Copy link
Contributor

@joelwarrington-jobber can we make sure that this description has a described-by relationship with the input?

Also I was wondering if there's consideration for how this would work if an input also has validation enabled (does the error text replace the description, or stack beneath it?)

@adambobadam
Copy link
Contributor

Hey @chris-at-jobber This is what the description field and the validation looks like when they are both present.

image

@adambobadam
Copy link
Contributor

adambobadam commented Oct 4, 2021

Hey @joelwarrington-jobber would splitting this PR up into two different ones make sense?

There seems to be a big change to the FormField tests and it might be good to see all the changes separately and make sure just the description is passing for now. It would separate the concerns into two, and would be a bit easier to manage.

What do you think?

The description part LGTM though (pending the described-by)!!!

@adambobadam
Copy link
Contributor

@chris-at-jobber Should there be a bit of space under the field?

space joel

@joelzwarrington
Copy link
Contributor Author

@joelwarrington-jobber can we make sure that this description has a described-by relationship with the input?

Also I was wondering if there's consideration for how this would work if an input also has validation enabled (does the error text replace the description, or stack beneath it?)

@chris-at-jobber Should there be a bit of space under the field?

space joel

Going to differ design considerations to @agglasaur as it's needed for some work we're doing

@agglasaur
Copy link
Contributor

@joelwarrington-jobber In most cases I think it makes sense for the description to appear with the error field stacked (looking at our usage of similar help text in Jobber Online) - it will be awkward with the password field as the help text is essentially the error as well - im not sure if its worth being able to "replace" it in that instance, or we...slightly reword it so its slightly less awkward?

Screen Shot 2021-10-05 at 9 09 34 AM

Otherwise, yes please add the spacing and the described-by

@chris-at-jobber
Copy link
Contributor

One visual note - can we either adjust the sizing of the error text to be small, or the description to use base? I would prefer base for both.

@agglasaur
Copy link
Contributor

@chris-at-jobber the checkbox and radio button description field use small by comparison - do you think those should be base?

@chris-at-jobber
Copy link
Contributor

Good catch... Those are small so that they're more obviously supplementary to the checkbox/radio label; here I don't think we need to enforce that hierarchy as aggressively as the label is contained in the input. We could go small for both the error and the description, but I don't think there's an issue with the size of the error validation as it stands currently.

@joelzwarrington joelzwarrington requested review from chris-at-jobber and removed request for agglasaur October 6, 2021 15:23
@chris-at-jobber
Copy link
Contributor

chris-at-jobber commented Oct 6, 2021

Seeing an unexpected inconsistency in the spacing when InputText is used in isolation, vs in a Form:

Alone:

image

In a Form:

image

It looks like the culprit is the Content wrapper, which uses a > selector. When I remove it from the Form example, the description spacing is correct, but the Form collapses in on itself:
image

I know we have some component-specific reactions to Content in places like Card, Tabs, and Modal - is this another place where we need that, or do we need a wrapper div around the entire InputText + description + error container for this to work?

EDIT: possibly related to this existing open issue?

@darryltec
Copy link
Contributor

darryltec commented Oct 6, 2021

@chris-at-jobber Not really related to that issue. What's happening here is, like @TJKruitbosch said,

The FormField-implementing components aren't an enclosed single thing

So either

  1. We enclose the FormFieldWrapper with a <Content /> instead of a fragment (</>) and let it handle the spacing between the input, description, and error so we won't need to worry about writing margin css for each element.
  2. Keep those margins but wrap it in a div. AKA replace the fragment with a div

Either way, it needs to be contained by a single element since even if we find a fix for the Content component, it's just a matter of time until someone wraps those fields in a display: flex | grid and we back to square one 😛

@joelzwarrington joelzwarrington added the hacktoberfest Some SPOOKY issues for Hacktoberfest. label Oct 7, 2021
@joelzwarrington
Copy link
Contributor Author

@darryltec can you please review this?

@darryltec
Copy link
Contributor

darryltec commented Oct 19, 2021

Will do first thing tomorrow!

Copy link
Contributor

@darryltec darryltec left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! Sans the input group issue tho.

I would've loved it if the test refactor was done on a different PR as most of it is really unrelated to this whole PR. It could've gone out first too. Basically that unrelated change makes this longer to review.

packages/components/src/FormField/FormField.tsx Outdated Show resolved Hide resolved
packages/components/src/FormField/FormFieldWrapper.tsx Outdated Show resolved Hide resolved
packages/components/src/FormField/FormField.test.tsx Outdated Show resolved Hide resolved
packages/components/src/FormField/FormField.test.tsx Outdated Show resolved Hide resolved
packages/components/src/FormField/FormField.test.tsx Outdated Show resolved Hide resolved
packages/components/src/FormField/FormField.test.tsx Outdated Show resolved Hide resolved
packages/components/src/FormField/FormField.test.tsx Outdated Show resolved Hide resolved
packages/components/src/FormField/FormField.test.tsx Outdated Show resolved Hide resolved
</div>
`);
});
// eslint-disable-next-line max-statements
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any way you can group more things and not have to declare this?

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 think the way it's done right now is best and think grouping more provides less value, I really don't like this eslint exception for tests

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that's fair!

@@ -96,8 +104,16 @@ export function FormFieldWrapper({
<AffixIcon {...suffix} variation="suffix" size={size} />
)}
</div>
{error && !inline && <InputValidation message={error} />}
</>
<div>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah yeah, this will get rendered with no children and the Content will addd a spacing between thus, adding a default margin bottom on all inputs.

In turn, it does this on the input group

image

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

resolved in 1ab04e9, decided to go back to the margin top styling instead of using content as it's difficult to get working with the InputGroup

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@joelwarrington-jobber Keep in mind that it does bring back these issues

image

image

That said

You can also ensure that the empty div doesn't show up

      {!inline && (description || error) && (
        <div>
          {description && (
            <FormFieldDescription
              id={descriptionIdentifier}
              description={description}
            />
          )}
          {error && <InputValidation message={error} />}
        </div>
      )}

Then go to the input group css and update the horizontal code from flex to grid so you can control how it's laid out through the parent class

.horizontal {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(0, 1fr));
}

This could also be a fast-follow since the spacing issue when used under a <Form /> existed before this PR introduced the description. Description wise, it works!

Copy link
Contributor

@darryltec darryltec left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The addition of description and test changes looks good to me.

Tho, there are some visual bugs that have been surfaced by QA'ing this that should be fixed on a different PR since it wasn't introduced by this PR. This comment explains how it can be fixed.

image

@darryltec darryltec merged commit 3fae72e into master Oct 29, 2021
@darryltec darryltec deleted the add-description-field-to-inputs branch October 29, 2021 15:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

5 participants