-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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(NumberInput): add warn prop #6652
feat(NumberInput): add warn prop #6652
Conversation
Deploy preview for carbon-elements ready! Built with commit a122d41 |
Deploy preview for carbon-components-react ready! Built without sensitive environment variables with commit a122d41 https://deploy-preview-6652--carbon-components-react.netlify.app |
@@ -78,10 +78,11 @@ | |||
|
|||
input[data-invalid], | |||
.#{$prefix}--number[data-invalid] .#{$prefix}--number__input-wrapper, | |||
.#{$prefix}--number[data-warn] .#{$prefix}--number__input-wrapper, |
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.
Was looking at this PR real quick, is data-warn
to match the data-invalid
convention above? 👀 If it helps, I think we could go down a class-driven approach for this as the data-*
states traditionally come from vanilla if I remember correctly
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 this was mainly to follow the same "predictable" behaviour for the developer. In case a custom style or some logic is in place that utilizes [data-invalid]
as the css selector, it would be more intuitive to select the warning state with [data-warn]
than by naming the classes.
I'm open to changing it to a classname though, in which case I would also update the TextInput.js
to remove its data-warn
and also soley rely on the --warning
modifier.
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.
@joshblack Just to clarify now, do we want to follow the [data-warn]
or the --warning
class convention?
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.
Hey @janhassel! So sorry about the delay, --warning
should be good going forward!
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.
@joshblack All good. Changed it accordingly 🙂 (cc @emyarod @andreancardona)
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 to me pending visual review
bump @andreancardona @jeanservaas when you have a chance to review 👀 |
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.
@janhassel looks good!
bump @jeanservaas @aagonzales if you have a sec to review 👀 |
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! Matches the TextInput warning.
Related: #5918
This PR adds a
warn
prop to theNumberInput
component to follow the behaviour added to the text input so far (see issue PR above).Changelog
New
props.warn
andprops.warnText
toNumberInput
Changed
_form.scss
to display warning messages (when input hasdata-warn
)Testing / Reviewing