Theme & Docs for Form #1555
Theme & Docs for Form #1555
Conversation
BREAKING CHANGE: removes `body` and `caption` variants in favor of MUI's `body1` and `subtitle`
…s into a single group
edburyenegren-okta
requested review from
a team,
ganeshsomasundaram-okta,
KevinGhadyani-Okta and
kamronbatmanghelich-okta
as code owners
| lineHeight: theme.typography.body.lineHeight, | ||
| lineHeight: theme.typography.body1.lineHeight, |
There was a problem hiding this comment.
body1 is MUI's default for this typography style. We had previously simplified this to body; however, MUI utilizes the style in different places, so I've changed the name back for now.
| "& + &": { | ||
| ".MuiButton-root + &": { |
There was a problem hiding this comment.
I feel like this could totally break at any point in time. I get that it's not your HTML.
There was a problem hiding this comment.
Yeah, this isn't especially safe. Once we have <ButtonGroup> done, we can remove this sibling styling altogether.
Alternately, I can see if there's a MuiButtonClasses to pull from.
| defaultProps: { | ||
| margin: "normal", | ||
| }, |
There was a problem hiding this comment.
What's margin: 'normal'?
There was a problem hiding this comment.
Here, margin is a prop and not a CSS Property. There are none, normal, and dense variants in MUI.
| ### Length | ||
|
|
||
| In general, it is good for forms to be as simple and short as possible. Eliminating unnecessary fields will reduce user effort and translate to better completion rates. | ||
|
|
||
| Often in products like Okta, it will be difficult to avoid more complex forms for things like settings or configurations. In these cases based on context, it is an acceptable solution. |
There was a problem hiding this comment.
I don't understand what this means about context.
|
|
||
| The `Form` component is designed in a single-column layout to maintain a logical flow of completion. | ||
|
|
||
| Adding multiple columns in a form can generate confusion for users and lead to usability problems such as having more than one way to interpret the form and forcing users to reorient their eyes to different places in the form. |
There was a problem hiding this comment.
I like bolding important statements in sentences to make them easier to scan. What do you think?
| Adding multiple columns in a form can generate confusion for users and lead to usability problems such as having more than one way to interpret the form and forcing users to reorient their eyes to different places in the form. | |
| Adding multiple columns in a form can generate confusion for users and lead to usability problems such as having more than one way to interpret the form and forcing users to **reorient their eyes** to different places in the form. |
There was a problem hiding this comment.
With this and the docs question above, Gretchen and Content Design are going to be reviewing, so I'd rather leave this type of stuff up to them.
| <Box | ||
| component="div" | ||
| sx={(theme) => ({ | ||
| marginBottom: theme.spacing(6), | ||
| })} | ||
| > |
There was a problem hiding this comment.
Is there a better way to write this using useTheme? I'd like to promote that method in our stories over functions in sx.
There was a problem hiding this comment.
afaik this is the best way to access theme variables for <Box>, since it doesn't have default styles or slots. I don't like the style-type application either, though.
I'd like us to get <Form> wrapped/exported asap so that downstream teams aren't doing this themselves.
Description
This PR adds documentation, stories, and styles for Form-related components.
The stories are a template for future
FormandFieldGroupcomponents. For now, this acts as a guide to self-assembly until those components are available.TODO