Upgrade React Aria and validate number fields without clamping - #3377
Open
david-crespo wants to merge 4 commits into
Open
Upgrade React Aria and validate number fields without clamping#3377david-crespo wants to merge 4 commits into
david-crespo wants to merge 4 commits into
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
david-crespo
force-pushed
the
react-aria-upgrade
branch
from
September 9, 2026 21:49
5e948cb to
1feda31
Compare
david-crespo
added this pull request to stack #3378
September 9, 2026 23:11
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is on top of #3376, which made
NumberFieldvalidateminandmaxitself so we could stop relying on react-aria's clamping. This PR upgrades react-aria 3.44 → 3.52.1 and react-stately 3.32 → 3.50.0 and turns off clamping with the newcommitBehavior: 'validate'option from adobe/react-spectrum#9679 (merged March 2026). It also adds whole-number validation toNumberField, which fixes a pre-existing bug: nothing client-side stopped you from submitting2.5CPUs.What changes for the user
Before, typing an out-of-range value and leaving the field rewrote it to the nearest bound. Now, if a value is out of range, or fractional in a field that requires a whole number, submit is blocked and the field shows an error. The validation trigger is still react-hook-form's default: no errors until the first submit attempt, and after that it revalidates on change events.
Form state updates on every keystroke that parses to a number, as long as the text is already in canonical form. react-aria's commit would rewrite
007or1.0to7or1, so those wait for blur or Enter, as they did before. Out-of-range values no longer wait: they used to sit in the input until blur while form state kept the old value, and now they reach form state immediately, which is what lets the error clear as soon as you fix the number.Disk size, min 6 GiB from the selected image:
5556, no message5, no message2020is in the boxPrefix length on the external subnet form, where the max depends on the selected pool (32 for v4, 128 for v6):
64646432, form still holds6464prefix_length: 64(main). On #3376, blocked with "Can be at most 32" under a box that says 3264reappears6432, form holds6464, "Can be at most 32"The middle row is the bug that motivated this.
useNumberFieldStateclamps thevalueprop we pass in before storing it, so the text in the box was derived from the clamped 32 while the value react-hook-form held (and would submit) was still 64. The validation from #3376 at least prevents submission, but the input still showed the wrong value. WithcommitBehavior: 'validate', the incoming value is used as-is.What stays the same
commitBehavioronly affects the typed value and the incomingvalueprop. Increment and decrement still go throughsnapValueToStep(prev, minValue, maxValue, step)and the buttons still disable at min and max. Pressing an arrow while the box holds an out-of-range value snaps it to the nearest bound (type2with min 10, press up, get10).007becomes7and1.0becomes1, as before.Whole-number validation
No form passes
step, so react-aria never snapped typed values to integers. On main,2.5in the CPU field is accepted as-is and sent to the API asncpus: 2.5, which Nexus 400s on. This is independent of clamping, but it is fixed here.NumberFieldnow checksNumber.isIntegerby default. Typing2.5CPUs leaves2.5in the box, but submit is blocked with "Must be a whole number". Correcting it to3clears the error. This covers CPU counts and CPU quotas, prefix lengths, firewall rule priority, disk sizes, and instance memory, including resize.Memory and storage quotas on silo create and quota edit opt into
allowDecimals. Those fields are entered in GiB and converted to bytes, so values like1.5 GiBare allowed. Instance memory and disk sizes still require whole GiB because the API enforces 1 GiB alignment for memory and disk sizes.Allowing decimals there exposed a pre-existing bug: the quota forms multiplied GiB by 2^30 without rounding, so
1.1 GiBsent a fractional byte count that the API rejects at deserialization. The last commit rounds to whole bytes in both submit handlers.One thing left for a follow-up: the mock API accepts fractional CPU counts and unaligned sizes that Nexus would reject. The right fix is in the generated Zod schemas, which currently don't enforce integer-hood: oxidecomputer/oxide.ts#382 (draft).
Tests
Every existing assertion that a value got clamped, in the
NumberInputbrowser spec and in the e2e specs for disks, instance create, and external subnets, is rewritten to assert the value stays put and the error appears. NewNumberInputcases cover the steppers stopping at the bounds and snapping an out-of-range typed value back into range. A newNumberFieldbrowser spec covers the whole-number rule andallowDecimals.The external subnet test is the regression test for the faux-clamping bug: type
64on a v4 pool, submit, switch to v6 and back. It fails on main and on #3376, where the box shows 32.React Aria packaging change
The lockfile got 1700 lines shorter because react-aria and react-stately now ship as single packages instead of dozens of
@react-aria/*and@react-stately/*deps, which also forced two imports inPopover.tsxandDateField.tsxto move to the top-level package.