-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request? input pattern #1328
Comments
I'm down for adding a pattern/mask feature to the input prompt. My only specific ask at this point is to match the HTML5 mask input API as closely as reasonably possible. |
@SBoudrias perhaps i'm blind, but with mask input you mean html5 pattern right? HTML5 pattern act a lot like validation (so it does not discard keys, but just validates against the pattern on submit). I'm not 100% convinced about my discarding mechanic tbh.
ot: what's the realease schedule of this package?, would like to use #1319 and #1329 if possible |
I was thinking something in the lines of https://css-tricks.com/input-masking/ in term of UX. |
Hallo, i've been using inquirer for a while now and this it#s quite elegant (slim & flexible).
That said I never got to warm with the
input
prompt as it seems to slim to me 😅Let's assume i want a number input, or a floating point input or a phone address input, currently with the
input
there#s no good way to archive it.Let's assume a simple prompt:
> Your most loved float: ...
, where the expected input is some float.When using the input component a user can enter whatever he wants and the options I have to fix this are:
Imo it would be nicer, if there was a way to just directly specify an allowed input pattern.
What i usually end up doing is adding a custom input component which in essence is a copy of the current input with the addition of:
inside of
useKeyPress
i then, just omit keys when the pattern would be invalidated:I'm wondering if that would be a welcome addition to the project? I'm not sold on the naming of paramters.
For me the RegExp was sufficient, but perhaps a more generic:
discardKey: (key, line) => {}
could be consideredThe text was updated successfully, but these errors were encountered: