[feature] Text input that accepts only numbers (or validation regex?)

[DenverCoder1]

It would be a neat idea to have input components for modals that only accept numbers as input.

Possible solutions

1. Have a new text input component type that would accept only numbers as input and would ignore non-numeric character input (similar to INTEGER Application Command Option Type).

2. Allow passing a validation regex for a Text Input component. In other words, when the modal submit button is pressed, the input would be checked against your validation regex and display an error to the user if it failed. For example, I could set the regex to something like [+-]?\d+ to only accept input in that form (optional plus or minus followed by one or more digits).

The first solution is a simple solution and would likely be more accessible to bot developers.

The second solution, however, would be more flexible and usable in more situations.

[MaskDuck]

go for this

[jagrosh]

I would like to see extensions on both of your ideas:

1. Support all existing application command option types (INTEGER, NUMBER, CHANNEL, ROLE, etc) other than SUB_COMMAND and SUB_COMMAND_GROUP (as those don't really make sense for Modals)
2. Add "REGEX" to the existing application command option types, which would be a String value with regex validation

[advaith1]

user, role, mentionable, and channel select menus are currently in testing for messages and will also be added to modals

pretty sure they don't want clients running arbitrary regexes

[Vexs]

There are regex engines without catastrophic backtracking or similar "reddos" issues and would be safe for a client to run. See re2 for example, which operates in linear time. Knowing this I can't see why it wouldn't be provided.

[jagrosh]

Google Forms supports regex and it seems to work fairly well; I don't know what their implementation is specifically, but that's at minimum an indication that arbitrary client-side regex is viable.

[mr-tech]

While not an explicit solution to client-side validation, I could also see augmenting #4615 with the ability to responding to a /error endpoint with custom_ids mapped to error strings of components. I see updating the modal with component-specific errors as a reasonable alternative to the idea of "communicate to the user what's acceptable input" and it also solves the problem of not being able to arbitrarily validate information.

I would also like to see field subheaders. Headers + subheaders could be used to communicate what type of input is acceptable, then the dev can validate however they want when the form is submitted, updating the modal with errors on what components are invalid and why.