[material-ui][InputBase] Add `warning` flag similar to the `error` flag
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 99.1k
- Forks
- 32.5k
- Avg merge
- 2d 17h
- Merged PRs (30d)
- 106
Description
Summary
Add a boolean prop warning to InputBase (and propagated to OutlinedInput, FilledInput, TextField) that behaves like the error prop but applies the "warning" visual style to the input, label (optionally), and helper text. When both error and warning are set, error must take precedence.
This should be used for situations where the user enters a value that is not necessarily erroneous (such as invalid email address) but for values that are valid but are unsafe in some way (i.e., disabling 2FA, its not invalid but a warning flag with a helper text could be used to inform the user to keep 2FA on).
Examples
The screenshot and code snippet below demonstrates the expected behaviour. Setting the warning flag would format the InputBase and helperText to the "warning" color palette.
import * as React from 'react';
import Box from '@mui/material/Box';
import TextField from '@mui/material/TextField';
export default function WarningHelperText() {
return (
<Box sx={{ display: 'flex', alignItems: 'center', '& > :not(style)': { m: 1 } }}>
<TextField
helperText="Please enter your name"
id="demo-warning-helper-text"
label="Name"
warning
/>
<TextField id="demo-warning-no-helper-text" label="Name" warning focused />
</Box>
);
}
In situations where both the error and warning flag have been set, the error flag should take precedence.
Motivation
I am developing a shader program app that uses a mixture of React Hook Form and React-Flow to create a graph of interconnected nodes. Each node being a member of the over-arching RHF. The user can configure a node to do something (i.e., multiple the input alpha/opacity by a given value). What they enter could be valid (i.e., the backend service would have no problem with it) however, they could be something wrong which the user should be aware of (i.e., the input alpha/opacity is 0 so multiplying the input alpha/opacity would do nothing).
I am aware that the InputBase has a color prop that can be used to set the InputBase to "warning" color. However, this do not set the helperText color. Yes, I am also aware that I can manually change the color of the helperText to match the color prop to keep them in-sync. However, for a regularly used feature, I would prefer if I didn't need to duplicate code everywhere.
Scope/Proposal
- Add boolean
warningprop to:InputBase,OutlinedInput,FilledInput,InputLabel(should visually reflect warning viaFormControl),TextField(forward toFormControl),FormControlcontext /useFormControl,FormHelperText(readFormControl.warningand render warning color whenwarning === trueanderror !== true)
- Precedence: If
error === true, error styling overrides warning. - Accessibility:
aria-invalidmust only be set for error states (warning must NOT setaria-invalid).- Keep
aria-describedbylinking to helper text so assistive tech reads warning helper text.
- Theming:
- Use
theme.palette.warning[ main/dark ](follow how error usestheme.palette.error) - Allow overrides via
theme.components.MuiFormHelperText/MuiInputBasestyleOverridesand variants.
- Use
- Docs:
- Add
TextField/InputBasedemo for warning + helper text. - Document when to use warning vs error (non-blocking vs invalid).
- Add
- Tests:
- Unit tests for
FormHelperTextrendering warning color. - Unit tests for
InputBasefocus/outline in warning state. - Test precedence: both error + warning => error styles applied.
- Assert
aria-invalidis only set for error.
- Unit tests for
Search keywords: input warning error flag
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the InputBase, OutlinedInput, FilledInput, TextField, InputLabel, FormControl, useFormControl, and FormHelperText entry points named in the proposal, then review their existing error-state tests and theme handling. Define the warning propagation, error precedence, helper-text styling, accessibility behavior, documentation demo, and unit-test coverage described in the scope.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript, react
- Domain
- accessibility, design, frontend, testing
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100