UX: delay error showing config

[bluebill1049]

Context

One of the primary focuses of React Hook Form is to provide a better and consistent user experience when customers interact with our forms. For example, we introduce mode config, so as a developer you wouldn't need to manually handle error states while let hook form taking care of them consistently.

Problem

The current mode is limited and has a strong connection with validation, while not giving the developer optimized behavior in terms of when and how much delay to show an error message.

(According to some of the research which has been done in the previous feature request: )
Following are resources and research on the topic.

From UX Planet:

Users dislike when they go through the process of filling out a form only to find out at submission, that they’ve made an error. The right time to inform about the success/failure of provided data is right after the user has submitted the information. Real-time inline validation immediately informs users about the correctness of provided data. This approach allows users to correct the errors they make faster without having to wait until they press the submit button to see the errors.

However avoid validating on each keystroke because in most cases you simply cannot validate until someone has finished typing their answer.

From designmodo:

Inline form validation that immediately informs users about the correctness of provided data results in an increase in the conversion rate.

From designer Andrew Burton:

the most commonly used moments to display validation are, instantly, and once a page has been submitted.

When using instant validation display messages after the user has input answers [with a delay]

From a Baymard Institute UX Research Article:

For most field types, the validity may be checked once the user leaves the field (by binding to the onblur event of the field).

From a UX design series sponsored by Adobe:

The time at which you choose to display an error message is vital. Seeing an error message only after pressing the submit button might frustrate users. Don’t wait until users finish the form; provide feedback as data is being entered.

Don’t validate after each character typed.

This approach not only increases the number of unnecessary validation attempts, but it also frustrates users (because users will likely see error messages before they have completed the field). Ideally, inline validation messages should appear around 500 to 1000 milliseconds after the user has stopped typing or after they’ve moved to the next field.

---

Feature request

#1321
#5810

---

Proposal

useForm({
  delayUserError: 500,
})

name options

• delayUserError
• delayError
• debounceError

This is yet to be confirmed above.

This config will allow user error to be delayed by 500ms, and it's configurable at the form level. if you would like to overwrite such behavior, then you can use trigger to trigger instant validation results per field.

What will this config do internally?

• validation will still be triggered each input change
• watch will still be updated with user interaction
• error message will be delayed (denounced) to the latest and show after user finish typing with xxxms

---

PR

[bluebill1049]

cc @jorisre @kotarella1110

[jorisre]

delayError sounds good to me

[bluebill1049]

@bluebill1049 Does this mean debounce?

Not 100%, only debounce when there is an error. We don't do debounce when the user corrected an error. The rational input debounce will debounce all changes, which is not desired user experience.

[bluebill1049]

Also, does this only work when in onChange mode?

This feature applied to all mode :)

[bluebill1049]

What is the difference between each of the following options?

• delayUserError
• delayError
• debounceError

Just prop name options, want to give it a simple and easy understanding config name.

[bluebill1049]

Sorry for the multiple questions 🙏🏻
Does this also delay when the error disappears?

Love all the questions! hopefully they all answers.

[bluebill1049]

@jorisre you win on the API name.

[bluebill1049]

This feature is released in 7.12.0

[skhoroshavin]

This is a great feature (of an awesome library), however I wonder - why delay only error status update, why not debounce validation itself as well? That would greatly simplify things when one needs to trigger external API in validation code (for example - check if user already exists in signup form) without doing that on each keystroke.

Also I'm aware of this solution, however in my opinion it is sub-optimal for two reasons:

• unless "leading" mode is used it adds debounce delay to form submission (because additional validation step is done on submit - btw was that intended?)
• it requires additional dependency

And yet another solution doesn't seem to work with V7 library at all.

[bluebill1049]

This is not debounced, it only delays errors as the config name suggested. We are delay error, but remove error is instant, also it doesn't affect formState such as isValid. Good questions tho, join the RFC early next time, i think it will be quite useful for such discussion.

[skhoroshavin]

@bluebill1049 yes, I understand current implementation, I was asking whether there was any particular reason to do it that way ) If there are no - I guess I could try raising feature request and/or try to work on PoC implementation. I wonder how process for such contribution should look like?

Good questions tho, join the RFC early next time

Is there any doc on RFC process here, and how to start/join it?

P.S. I became aware of that library just 3 days ago, and started dabbling in front end only 2 weeks ago - for example that's why I was not sure whether debouncing validation on library side is a good idea or not, and came here asking questions.