BigNumberField: controlled mode cannot represent an empty field

[kemuru]

Version: 3.9.0 — src/lib/form/bignumber-field/useBigNumberField.tsx

Four related behaviours make a controlled BigNumberField unable to express "empty", so consumers
resort to remounting the field and reading the raw input text (kleros/kleros-v2#2281:
web/src/hooks/useBigNumberFieldReset.ts, Resolver/Landing/CreationCard.tsx, the stake and
appeal amount fields).

1. An emptied input is reported as 0. handleChange: if (newInputValue === "") { …; onChange?.(new BigNumber(0)) }.
   The consumer cannot tell "cleared" from a typed 0 (which is a valid dispute ID, for example).
2. value="" renders NaN. The initial/sync path does new BigNumber(value.toString()) → NaN → toFormat() → "NaN".
3. value={undefined} is ignored. The sync effect is if (value !== undefined) { setInputValue(value.toString()) … },
   so once a value has been shown there is no prop that empties the field again (e.g. resetting an amount after a
   transaction popup closes).
4. The sync effect rewrites the text on every numeric change. With value={amount} onChange={v => setAmount(v.toString())}
   each keystroke echoes a new value and setInputValue(value.toString()) replaces what the user typed: 1.05 →
   Backspace → 1 (not 1.0), so typing 3 yields 13. Holding a BigNumber in state is worse (new object each
   render → cannot type 1. at all).

Proposal

• Model empty explicitly: onChange(null) when the input is emptied (type (value: BigNumber | null) => void), and
  accept value={null} / value="" to clear the input.
• In the sync effect, skip when the incoming value is numerically equal to the current numberValue
  (new BigNumber(value).isEqualTo(numberValue)), so the field's own onChange echo is a no-op and in-progress text
  such as 1.0 survives.