Skip to content

fix: forward isInvalid to Select and DatePicker trigger ring - #199

Draft
simonyang08 wants to merge 1 commit into
untitleduico:mainfrom
simonyang08:codex/uui-187-select-datepicker-invalid-ring
Draft

fix: forward isInvalid to Select and DatePicker trigger ring#199
simonyang08 wants to merge 1 commit into
untitleduico:mainfrom
simonyang08:codex/uui-187-select-datepicker-invalid-ring

Conversation

@simonyang08

Copy link
Copy Markdown

Fixes #187

Description

Select and DatePicker accept isInvalid, which react-aria-components forwards to the root (so aria-invalid and data-invalid are set for assistive tech). However, the visible trigger button rendered by each component never received the invalid state in its className, so the ring stayed neutral even when validation had failed. Sighted users had no way to tell at a glance which field was in error.

This PR aligns both triggers with the convention already used by Input (see components/base/input/input.tsx:109-114):

  • Select: thread state.isInvalid into SelectValue, add ring-error_subtle at rest and ring-2 ring-error on focus/open.
  • DatePicker: read isInvalid from DatePickerStateContext and apply ring-error_subtle to the trigger Button.

Changes

  • components/base/select/select.tsx — destructure isInvalid from the spread {...state} and add the error ring classes to the trigger button.
  • components/application/date-picker/date-picker.tsx — introduce a small DatePickerTrigger component that consumes DatePickerStateContext and forwards isInvalid to the trigger Button.
  • tests/invalid-ring.test.tsx (new) — vitest + @testing-library/react regression test asserting that ring-error_subtle appears on the trigger button when isInvalid is set and does not appear when it is not.
  • vitest.config.mts (new) + 3 devDeps in package.json — minimal test infrastructure. The repo did not previously ship a unit test runner.

Testing

  • New unit test passes: 5/5 (vitest run tests/invalid-ring.test.tsx)
  • No new tsc errors (3 pre-existing errors are unrelated to this change).
  • No new eslint errors (0 errors repo-wide; only CRLF warnings, consistent with the existing source-tree line-ending style).
  • No new prettier warnings.
  • Storybook visual confirmation (recommended before merge — the sandbox does not have a browser available).

Related issues

Scope note

The same invalid-ring gap exists in MultiSelect, TagSelect, and ComboBox (verified via grep on ring-1 ring-primary branches). Those are intentionally out of scope here to keep the diff under the repo's 5-file / 200-LOC convention. Happy to follow up with a separate PR once this lands.

…ntitleduico#187)

The Select trigger button hardcoded its ring color and only branched
styling on isFocused/isOpen/isDisabled. The DatePicker trigger used a
generic Button that had no concept of invalid state at all. In both
cases the isInvalid prop was forwarded to the underlying react-aria
root for assistive tech but never reached the visible trigger, so
users couldn't tell at a glance which field was in error.

Add the error ring token (matching the existing Input convention) to
both triggers. The DatePicker now reads isInvalid from
DatePickerStateContext to keep the data flow local to react-aria.

Adds vitest + @testing-library/react + jsdom as devDeps and a single
regression test that asserts the trigger button's className contains
ring-error_subtle when isInvalid is set, and does not when it is not.

Signed-off-by: simonyang08 <ppt5928@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: Select and DatePicker do not show invalid styling when isInvalid is true

2 participants