-
Notifications
You must be signed in to change notification settings - Fork 30
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
Conversation
✔️ 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 |
@joelwarrington-jobber can we make sure that this description has a 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?) |
Hey @chris-at-jobber This is what the description field and the validation looks like when they are both present. |
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 |
@chris-at-jobber Should there be a bit of space under the field? |
Going to differ design considerations to @agglasaur as it's needed for some work we're doing |
@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? Otherwise, yes please add the spacing and the |
One visual note - can we either adjust the sizing of the error text to be |
@chris-at-jobber the checkbox and radio button description field use |
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. |
Seeing an unexpected inconsistency in the spacing when InputText is used in isolation, vs in a Form: Alone:In a Form:It looks like the culprit is the I know we have some component-specific reactions to EDIT: possibly related to this existing open issue? |
@chris-at-jobber Not really related to that issue. What's happening here is, like @TJKruitbosch said,
So either
Either way, it needs to be contained by a single element since even if we find a fix for the |
@darryltec can you please review this? |
Will do first thing tomorrow! |
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.
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.
</div> | ||
`); | ||
}); | ||
// eslint-disable-next-line max-statements |
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.
Any way you can group more things and not have to declare this?
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 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
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.
that's fair!
@@ -96,8 +104,16 @@ export function FormFieldWrapper({ | |||
<AffixIcon {...suffix} variation="suffix" size={size} /> | |||
)} | |||
</div> | |||
{error && !inline && <InputValidation message={error} />} | |||
</> | |||
<div> |
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.
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.
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
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.
@joelwarrington-jobber Keep in mind that it does bring back these issues
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!
…el' and removed snapshot portion
…ocument instead of being an instance of element
…argin top as to avoid issues with InputGroup
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 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.
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
Changes
Added
Changed
Describe
so it's easier to followTesting
description
to any input which is inheriting FormField props, such asInputText
,InputPassword
,Select
Multiline
inputsIn Atlantis we use Github's built in pull request reviews.