mui / mui/material-ui

[material-ui][InputBase] Add `warning` flag similar to the `error` flag

Open
#47,154 7 comments 3 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

package: material-ui scope: text field type: new feature waiting for 👍
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.

Image
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 warning prop to:
    • InputBase,
    • OutlinedInput,
    • FilledInput,
    • InputLabel (should visually reflect warning via FormControl),
    • TextField (forward to FormControl),
    • FormControl context / useFormControl,
    • FormHelperText (read FormControl.warning and render warning color when warning === true and error !== true)
  • Precedence: If error === true, error styling overrides warning.
  • Accessibility:
    • aria-invalid must only be set for error states (warning must NOT set aria-invalid).
    • Keep aria-describedby linking to helper text so assistive tech reads warning helper text.
  • Theming:
    • Use theme.palette.warning[ main/dark ] (follow how error uses theme.palette.error)
    • Allow overrides via theme.components.MuiFormHelperText / MuiInputBase styleOverrides and variants.
  • Docs:
    • Add TextField/InputBase demo for warning + helper text.
    • Document when to use warning vs error (non-blocking vs invalid).
  • Tests:
    • Unit tests for FormHelperText rendering warning color.
    • Unit tests for InputBase focus/outline in warning state.
    • Test precedence: both error + warning => error styles applied.
    • Assert aria-invalid is only set for error.

Search keywords: input warning error flag

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.