more flexible validation options for open text inputs

Is your feature request related to a problem? Please describe. First of all, great work on this lib, it’s pretty useful and i’m glad i found it instead of setting this stuff up myself within my app. Thanks for all of your work on it!

Unfortunately, I cannot update to 2.0 because of the way validation has changed in the 2.* versions. It’s a very simple and minor difference, but it’s quite impactful for the end user experience in mine (and probably most apps).

Here:

export function showError({ meta: { submitError, dirtySinceLastSubmit, error, touched, modified } }: showErrorProps) {
	return !!(((submitError && !dirtySinceLastSubmit) || error) && (touched || modified));
}

Just by adding that || modified makes it so that field validation is triggered as soon as the user starts typing, which in the case of validation like “email” for instance, the user doesn’t even get one chance (until they focus out of the field) to get it right. Which results in overly aggressive validation. As I type this I’m wondering if the intention was maybe to check if it was touched && modified instead of the OR?

Describe the solution you’d like I think it would be sweet if we could either drop the modified check, or make that part optional either via prop, or an override that could be provided to determine when a field is in an error state.

I’m likely going to modify what i need in a fork and publish it to our private NPM at work, but would be interested in your thoughts, or if there’s a simple workaround i’m missing. Thanks!

Edit: btw i would love to help and submit a PR for this, just want to make sure i’m not missing anything first. Let me know.

[lookfirst]

Hi @alexjsdev! Thanks for the report!

I’d hate for you to have to maintain your own fork. I’m totally open to fixing this and making things right.

The big issue is that validation is a touchy/modified subject (punny!)… what if you do want to validate on modified? Maybe && is the right solution there … need to test and see what works right.

At the end of the day, what I think really needs to happen is that this showError function needs to get abstracted out such that it can be defined externally. 2.x got us that function extracted, so that was step 1. Step 2 is to make it so that people can override the behavior.

I think eventually I want to get this library to a state where something can be written on top of it to build forms with a DSL. I recently learned about Data Driven Forms, which is effectively a duplicate of this project, with even more functionality on top of it. I’m not sure I fully agree with their implementation (no typescript and it is a bit too complex imho), but having a DSL to describe forms is a great idea. Getting that DSL to do validation in all the various cases people can come up with, is going to be tough though.

[lookfirst]

Closing, this hasn’t come up in years. If it is still an issue, we can reopen.