DiamondLightSource / DiamondLightSource/sci-react-ui

Change Proposal: Restrict keystrokes in `NumberInput` to characters valid for the selected `numberMode`

オープン
#276 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る
needs-triage
主要言語
TypeScript
スター
8
フォーク
3
平均マージ
3日 15時間
マージ済み PR(30日)
5

説明

## What is being proposed?

As discussed in [Atlas #143](https://github.com/DiamondLightSource/atlas/pull/143#issuecomment-5207977415), the `NumberInput` currently accepts any keystroke into the underlying `TextField` and only flags invalid content after the fact. A user can type letters, symbols, multiple decimal points, etc., and only discovers the problem from the "Invalid input" helper text.

**Proposal:** filter keystrokes/paste input as they happen, so only characters that could ever be valid for the active `numberMode` are accepted:

* Natural: `0-9`
* Integer: `0-9`, `+`, `-`
* Floating: `0-9`, `+`, `-`, `.`
* Scientifc: `0-9`, `+`, `-`, `.`, `e`/`E`

## Why is this needed?

- A `natural` mode field currently lets a user type `-5`, rejecting it only after the fact. Blocking `-` at keystroke time prevents that error state from being reachable at all.
- For `integer`/`floating`/`scientific`, `-` must stay typeable (including mid-entry, e.g. `-` alone or `-1`.).
- Filtering at input time avoids the most common invalid keystrokes (letters, symbols) ever reaching `numberText`. It doesn't catch positionally-invalid strings like `12-3` or `1.2.3`, and those still rely on the existing whole-string validation on blur/submit.

## Known limitations

Dropping a keystroke silently (character never appears) gives no feedback to screen reader users, unlike the current visible error state. The implementation should pair the filter with some non-visual signal so this isn't a regression for assistive technology users.

## What will change?

`NumberInputText` filters out characters that are not in the allowed set for the active `numberMode` before they're accepted. When a keystroke is rejected, the field gives a lightweight signal that something happened (e.g. a brief visual cue, and an `aria-live="polite"` announcement so screen reader users aren't met with silence). Whole-string validation is unchanged. No new props required.

## Interface changes (if any)

None required by default. Optional escape hatch if any keys are desired.

## Breaking change?

- [ ] Yes
- [X] No

## Next steps
A maintainer will review this issue.
If accepted, it will be marked as `accepted` and a PR may then be opened.

コントリビューションガイド

コントリビューションガイドを開く

調査の方向性

NumberInputText から始めて、その基盤となる TextField がキーストローク入力と貼り付け入力をどのように受け取るかを、numberText に対する既存の文字列全体のバリデーションと併せて追跡します。numberMode が許可される文字をどのように選択するか、また拒否された入力が視覚的なシグナルまたは aria-live シグナルをどのように提供できるかを確認します。完了の条件は、フィルタリングが記載された4つのモードに従い、必要な場合に入力途中の符号を引き続き入力でき、文字列全体のバリデーションが変更されないことです。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
typescript
領域
frontend
issue の種類
機能追加
難易度
4/5
見積もり時間
3〜5日
活発さ
静か
明瞭さ
おおむね明確
初心者へのやさしさ
48/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。