feat(numeric-keyboard): expose keypad input rules for hardware keyboards - #16
Merged
Merged
Conversation
`NumericKeyboardView` renders buttons and installs no text responder, so a host that wants physical-keyboard support has to add its own responder and then needs the pad's input rules. They were `internal`, so the first host to do this reimplemented them and got the locale handling wrong: it mapped "," to the decimal separator in every locale, and typing "1,000" in `en_US` produced "1.000". Make `NumericKeyboardLocaleSupport` public and add `key(forTyped:locale:)`, which translates a typed character into the key the on-screen pad would have sent. The locale-sensitive rules — which separator is decimal, which is grouping and therefore dropped, at most one decimal separator, delete — stay in `applyKeyPress` alone, so both input paths agree by construction.
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
romchornyi
pushed a commit
to PastaPastaPasta/dashwallet-ios
that referenced
this pull request
Aug 28, 2026
dashpay/DashUIKit#16 made `NumericKeyboardLocaleSupport` public, so the app no longer has to carry its own copy of the keypad's input rules. `key(forTyped:locale:)` maps a typed character to the key the on-screen keypad would have sent, and `applyKeyPress` decides what that key does to the value. Both input paths now run the same code, so they cannot drift apart again — which is how "1,000" typed in en_US came to produce "1.000". The app-side tests go with the app-side copy; the rules are covered by `NumericKeyboardLocaleSupportTests` in the package, including the grouping-separator cases.
5 tasks
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.
Issue being fixed or feature implemented
NumericKeyboardViewrenders buttons and installs no text responder, so digits typed on a connected physical keyboard never reach it. A host that wants hardware-keyboard support has to add its own responder — and then it needs the pad's input rules, which wereinternalto the package.The first host to do this (dashwallet-ios #1040) reimplemented them app-side and got the locale handling wrong: it mapped
,to the decimal separator in every locale, so typing1,000inen_USproduced1.000— a silent 1000x error on the send and pay screens. The on-screen pad, which routes throughapplyKeyPress, drops the locale's grouping separator and gets1000.What was done?
NumericKeyboardLocaleSupportpublic, along withapplyKeyPress,decimalSeparator(for:)and a newdeleteKey.key(forTyped:locale:), which translates a character typed on a physical keyboard into the key the on-screen pad would have sent, ornilwhen the pad has no such key.The locale-sensitive rules — which separator is decimal, which is grouping and therefore dropped, at most one decimal separator, delete — stay in
applyKeyPressalone.key(forTyped:)deliberately passes the grouping separator through untouched instead of filtering it, so that rule has exactly one implementation and both input paths agree by construction.No behavior change for existing callers: the on-screen pad's code path is untouched, and the change to the type's surface is
internal→public.How Has This Been Tested?
swift build -c release— clean.swift test --filter NumericKeyboardLocaleSupportTests— 8 tests, 0 failures.en_US,de_DE, andde_CHwhere the typed character is neither separator), and that typing a grouped amount keeps its magnitude in bothen_US(1,000.5→1000.5) andde_DE(1.000,5→1000,5).Breaking Changes
None.
Checklist: