InputControl: Add padding wrapper for prefix/suffix #42378
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Size Change: +188 B (0%) Total Size: 1.26 MB
ℹ️ View Unchanged
|
ciampo
reviewed
Jul 14, 2022
There was a problem hiding this comment.
I'm not sure if naming props like exact CSS properties (i.e. paddingLeft and paddingRight) is a good idea — I usually prefer prop names that hide the implementation details.
Also, I'm not sure if there's a point in allowing consumers of the component to define a custom padding; I can imagine that 99.9% of the time, the requirements are either to have the default spacing, or to have no spacing at all.
With this in mind, I propose an alternative approach:
- the
InputControlPrefixandInputControlSuffixhave ahasSpacingboolean prop (an alternative name could behasInlineEndSpacingfor the prefix andhasInlineStartSpacingfor the suffix) - prop's default value TBD
- when the prop is
false, no padding is added - when the prop is
true, the padding corresponding to theInputControl's size is added (via internal styles)
WDYT?
That makes sense. However, when I tried to implement it, I realized that we can't accomplish what we want here using the Context System if we don't expose the But that prompted me to think of an alternative, simpler way, which is to remove
Sound good? |
An alternative way to the context system, maybe could have been to:
Out of curiosity, do you think that would work?
Sounds like a good solution, yes. Maybe we should call the components |
Without the context system, we'd need the consumer to explicitly pass a
Makes sense. Done in c697074 👍 |
|
Tests well in Storybook, although I noticed that we're using
Should we use logic CSS properties in this PR too? |
This PR uses the |
ciampo
approved these changes
Jul 20, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Follow-up to #42166
What?
Adds a convenience wrapper component
InputControlPrefix/InputControlSuffixthat can be used by a consumer to add standard padding that matches the size variant.Wrapped prefix when InputControl is at default size
Wrapped prefix when InputControl is at large size
(The padding between the prefix and the placeholder here is too wide — this will be addressed in #42166)
Why?
Currently, whenever a consumer wants to add padding before their
prefixelement, they need to add it themselves. This is not sustainable because they need to know the padding value of the underlyingInputControl, and that value also changes depending on the size variant.Here are the alternative approaches I considered, but decided against:
<CardMedia>approach taken in the Card component, and the approach considered forDropdown. Although it would be nice to have a similar construct forInputControl, the current implementation is already no padding by default. Also, it's arguably more natural in this case for the wrapper to add padding instead of break out of it, since we're only dealing with one side of the box. (A padding breakout wrapper deals with all four sides of the box.)prefixis a function, and if it is, call it with a{ paddingInlineStart }argument so the consumer can use that value to style their own margin. This seems simple on the surface, but it's just more work for the consumer, and forces them to use an inline style or a CSS-in-JS solution. Also, I think the general direction we're headed toward for these solutions is to use subcomponents likeCardMedia.How?
Provide a thin wrapper component that applies responsive padding through the Context System. This can be used with any InputControl-based component that inherits the
prefix/suffixprops.Testing Instructions
npm run storybook:devInputControl.