-
Notifications
You must be signed in to change notification settings - Fork 14
Conversation
a6118af
to
58a056e
Compare
101e41d
to
7832574
Compare
FormElement
componentFormControl
component
4b24f0a
to
7ebc0fa
Compare
2407a0a
to
014a8d9
Compare
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.
Awesome!! Just one one request about the info icon...
9e2a365
to
08d99c6
Compare
08d99c6
to
e8faf4d
Compare
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.
Gah, I'm sorry, I forgot to specify they should be text-grey
instead of text-blue
. 🙈
Approving anyway so feel free to merge with that tweak. 🙇
src/FormControl/index.tsx
Outdated
{startAdornment && ( | ||
<div | ||
css={{ | ||
position: "absolute", | ||
display: "inline-flex", | ||
left: 12, | ||
top: "50%", | ||
transform: "translateY(-50%)", | ||
}} | ||
> | ||
{startAdornment} | ||
</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.
(Please do merge at will / don't let this slow down delivery)
The styles around these wrappers for adornments don't look like they can be easily/safely overridden
Could FormStartAdornment and FormEndAdornment export styled divs that carried these styles by default?
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.
Yeah you're right that the adornment layout can't be overridden here. That's kind of unintentional and intentional at the same time. I wanted the components themselves to not have any layout styles in them; just what's needed to render them in isolation and then FormControl
would handle the layout. I provided escape hatches for some of the layout, but obviously not this part.
I think this will need to be re-worked, especially where we don't even make an attempt to measure the size of the adornments to pad the Input
and they just overlap the Select
.
I want to come back to this when we have a use case for it if that's cool.
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.
Yup of course, merge at will
If you don't mind, I am curious to fill out my mental model so I can better know what kind of feedback is useful to provide -- is the motivation for punting on making this portion of the component open for extension due to a desire to defer coding time? (My mental model might be missing some pieces to better weigh the tradeoffs of implementing this now)
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.
From my perspective of consuming components, since making changes for external dependencies is not quite frictionless, if/when a use case for this arises, I would prefer if the convenient thing to do also happened to be the right thing to do.
If these adornment components' styles are not open to extension/override, then the convenient thing for a consumer to do becomes to wrap itself with negative margins to work around not having access to the wrapper, which is more convenient from a time-and-effort perspective, but the resulting code would feel less than great
I would be curious to understand what costs or risks that ^ is trading off against
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.
@cheapsteak I was thinking in terms of "what's the use case and how should we prepare for that?" Going with a straightforward approach of just applying these css properties in FormStartAdornment
and FormEndAdornment
and allowing a className
override seems fair and frictionless so I added it; thanks for the pushback!
@jglovier grey it is! |
e8faf4d
to
ba3ec29
Compare
c1cb30f
to
a1d9f64
Compare
0f1ea1b
to
6b84ce4
Compare
6b84ce4
to
bfd93d0
Compare
🚀 PR was released in |
Create a new modular
FormControl
component.Reviewing
I don't really need a review here. I'm super open to any and all feedback; but it's more important to me to get this in people's hands ASAP. I'm going to merge this pretty quickly to help people start using it.
Release Notes
FormControl
There is a new component to handle forms;
FormControl
. It's a layout component that will automatically layout it's children.New components include:
FormLabel
,FormDescription
,FormInput
,FormHelperText
,FormStartAdornment
,ForEndAdornment
, andFormErrorMessage
. All of these components can be rendered anywhere on their own; but if they are rendered inside of aFormControl
then they will automatically communicate withFormControl
to add accessibility props and lay them out correctly.There is a new hook,
useFormControlContext
intended to be used by any user-component that needs access to information passed byFormControl
.Input
andSelect
both consumeuseFormControlContext
, for example.Select
initialValue
prop todefaultValue
to be inline with React's built-inslistAs
propFormControlContext
to accepterror
stateInput
New component to apply custom styles to
<input />
.📦 Published PR as canary version:
8.7.3-canary.287.7275.0
✨ Test out this PR locally via:
npm install @apollo/space-kit@8.7.3-canary.287.7275.0 # or yarn add @apollo/space-kit@8.7.3-canary.287.7275.0