Combination of synchronous and asynchronous debounced validators

[xgemelaj]

Because previous ticket (#888) was closed and there was still discussion about the problem in common case where you are validating new name with synchronous and also with asynchronous validation which is debounced. I am reopening discussion with the @martdavidson text where he described behaviour of this problem.

@bluebill1049 Can you take another look at this?

The synchronous validation returns false, and an error is shown. Then asynchronous validation resolves and returns true. The error state is now cleared.

Your codesandbox example doesn't have a synchronous validator. Something like:

validate: {
      specialCharacters: displayName =>
        meetsAlphaNumericRequirement(displayName) ||
        'The display name can only contain alpha-numeric characters.',
      unique: debounce(checkForUserWithSameDisplayName, 400),
    },

unique will always resolve after specialCharacters, so it doesn't matter what the result of specialCharacters was, unique's result will always overwrite it.

In this case, if I enter Bill$, specialCharacters fails and shows an error, and unique is not called with Bill$ because the criteria is set to firstErrorFound. But unique will fire with just Bill at this point, because that was the last value it was called with, and the debounce delay is triggered.

So one path I went down was to call getValues() inside of checkForUserWithSameDisplayName to get the value of the displayName field at the time that the debounce triggers and then call meetsAlphaNumbericRequirement() again at the top of that function like so:

async function checkForUserWithSameDisplayName(displayName // we actually don't even use this anymore) {
    if (!meetsAlphaNumericRequirement(getValues().displayName)) {
      return 'The display name can only contain alpha-numeric characters.';
    }
   // check uniqueness
}

This works, but then the type of the error is unique, not specialCharacters, if you care about that.

Ideally there'd be a way to maybe return undefined from a validator, which would act as though it had never been called, and the previous state of the form would remain.

Originally posted by @martdavidson in #888 (comment)

[bluebill1049]

what if you combine that validation logic into one which contains both async and sync validation and returns an error message accordingly?

validate: (value) => {
  if (Array.isArray(value)) {
     return await validation()
  }
  
  return regularValidation()
}

[bluebill1049]

in fact, can you reproduce the issue in this CSB: https://codesandbox.io/s/heuristic-brown-0qxrsc?file=/src/App.tsx

[mdjzon]

I have replicated the problem: https://codesandbox.io/s/objective-blackwell-o0qhxw?file=/src/App.tsx

There are now two validation functions, one sync that checks for the presence of digits and the async one that isn't particularly fond of periods.

Steps to reproduce:

1. Enter a digit and a period - eg 8.
2. Remove the period immediately.
3. Observe the error "Please remove period" appear for a brief second, which I believe it should not since it's the late incoming result from the previous validation.

In my first CSB the error remained though until a new validation was triggered so I imagine there is a slight difference in the RHF implementation in /src?

[bluebill1049]

Observe the error "Please remove period" appear for a brief second, which I believe it should not since it's the late incoming result from the previous validation.

This is because I subscribe to the isValid form state, and the entre form needs to be validated including both async and sync.

[lmacedotzt]

The enhancement done on version 7.40.0

Improved async validation and especially combined with sync ones, which will abort early sync failed first

Stopped working on version 7.41.1, the result of the async validation clears the latest error state of the input.

[kai-dorschner-twinsity]

This bug is still open and can still reproduced, even with the latest version v7.56.3: https://codesandbox.io/p/sandbox/sharp-black-l2ctgv

There is even a more weird bug:

1. write 8.
2. remove the period and write it back immediately

👎 What it looks like:

👍 What it should look like: