Skip to content
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

OTP Field #88

Open
logaretm opened this issue Dec 28, 2024 · 1 comment
Open

OTP Field #88

logaretm opened this issue Dec 28, 2024 · 1 comment
Assignees
Labels
📦 core-component A component composable 🍰 p3-low Tasks that are nice-to-have. Like minor bugs, non-essential features, or cosmetic changes. 🌟 ver-minor PR should have a minor version changeset type
Milestone

Comments

@logaretm
Copy link
Member

What

OTP inputs are tricky to build and naturally, they have multiple requirements and expectations.

The OTP input should have the following features:

  • Supports digits or characters.
  • Code length should be configurable, maybe a length prop?
  • Supports Paste/Backspace focus management and value filling.
  • Supports typing focus management between inputs.
  • Supports iOS/Android filling hints from messages.
  • Supports validation and error messages.
  • RTL direction.

Anatomy

There are two ways to build an OTP input, I do not think we should support both since they are wildly different.

Single Input Field

Easier to manage and fill as it is only 1 field.

 <input type="text"
         inputmode="numeric"
         autocomplete="one-time-code"
         pattern="\d{6}"
         required>

Validation will be easy to implement, but patterns will require some logic to prevent illegal characters.

You could style it to look like it has code boxes like in this article, but I do not think it feels nice at all and it is magic-number heavy.

Multi-input Fields

Each field would represent one code character, most UI libraries implement this pattern as it is more visually appealing and does inform the user about the length of the expected code implicitly.

I think this is the approach we should follow, I do not know about the a11y concerns around this.

Examples:

Extras

Web OTP API

This can be very useful for mobile devices, right now it is only supported on Chrome/Edge and their mobile counterparts, but we can support it regardless.

Resources

@logaretm logaretm added this to Roadmap Dec 23, 2024
@logaretm logaretm converted this from a draft issue Dec 28, 2024
@logaretm logaretm added this to the v1.0 milestone Dec 28, 2024
@logaretm logaretm added 🛠️ p2-medium Issues that should be addressed but are less urgent 🌟 ver-minor PR should have a minor version changeset type 📦 core-component A component composable labels Dec 28, 2024
@ahmadalfy
Copy link

I wanted to add this link, happy to find it's already in the list.

RTL direction is always ignored when OTP is implemented through multiple inputs. The container's direction should be LTR instead.

@logaretm logaretm moved this to Todo in Roadmap Jan 2, 2025
@logaretm logaretm added 🍰 p3-low Tasks that are nice-to-have. Like minor bugs, non-essential features, or cosmetic changes. and removed 🛠️ p2-medium Issues that should be addressed but are less urgent labels Jan 2, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
📦 core-component A component composable 🍰 p3-low Tasks that are nice-to-have. Like minor bugs, non-essential features, or cosmetic changes. 🌟 ver-minor PR should have a minor version changeset type
Projects
Status: Todo
Development

No branches or pull requests

2 participants