In v2-rc.9, isValid becomes true when not all required fields are filled in

[Satyam]

🐛 Bug report

For Formik v2.01-rc.9. isValid becomes true even if not all required fields are filled in.

Current Behavior

If you have a form with two fields and a Yup schema with both fields declared as required, once you type something valid on the first field, isValid turns true, since the second field, empty but untouched, doesn't get validated.

As I have the Submit button disabled when isValid and dirty are false, the user gets the wrong impression that the form is ready to submit. It eventually rejects the submission, and shows the error message, but the user is getting the wrong impression, after all, the interface enabled the submit button.

If you do start filling the second field, the submit button remains enabled but if you then backspace until the field is empty, the submit button gets disabled, as it should, and should have been the first time around as well.

Expected behavior

With v1, I used isInitialValid which forced all fields to be changed, and thus validated, before isValid becomes true.

Currently, I am using initialErrors with empty string on those required fields so, on the one hand, isValid is false and the error text, being an empty string, is falsy and doesn't distract the user with spurious error messages. (Actually, I get initialErrors filled in based on what I get from analyzing what schema.describe and checking for required fields)

Reproducible example

Sorry, codesandbox seems to be unable to fetch v2.0.1-rc.8 or 9. Most likely, I don't know how to do it right, sorry.

Suggested solution(s)

Either:

• Perhaps restore some of the funcionality of isInitialValid?
• Document the usage of initialErrors for this since I don't really know if what I am doing is correct or will be supported in the future. For example, if errors get checked more strictly, my trick of setting field errors to '' would stop working.
• Suggest a better way to fix this.

Additional context

Your environment

Software	Version(s)
Formik	2.0.1-rc.9
React	16.8.6
TypeScript	none
Browser	Chome 75.0.3770.100
npm/Yarn	npm 6.9.0
Operating System	Ubuntu 18.04.2

Thanks

[danielkcz]

Reproduction would be probably very useful here. I tried CodeSandbox and it indeed does have some issue with RC9, but RC8 can be used. Can you try if you can reproduce the issue with that version?

Also, any chance you are using setValues? You might have run into the same issue as I did #1560

[Satyam]

My apologies.

My sample in CodeSandbox (https://codesandbox.io/s/mystifying-leaf-j4hc6) works as expected without any problem.

I probably have something in my existing code that doesn't translate well to v2.

I'm closing this issue. I'll find what is at fault and if it is not on my side, I would re-open it.

Sorry and thanks

[Satyam]

The issue does exist with v2.0.1-rc.9 but it does not with rc.8. I found the issue in my local environment using rc.9, but that one was not available in CodeSandbox.

I have now downgraded my local environment to use rc.8 and now it works as expected, no problem. Something changed in between rc.8 and rc.9 that brought the reported problem.

I am perfectly fine trying out rc.8, but you might want to know about the issue.

[danielkcz]

I am fairly certain that RC9 is some kind of publish mistake. There is no mention of that version anywhere, no commits, no tags, no releases. It's not even under the @next dist tag, so I wonder where did you get it :)

[Satyam]

The same place you got that screenshot from, npm. It might be wise to unpublish it after tracing its origin.

[danielkcz]

Well as you can see in that screenshot, if you have installed formik@next you would've got RC8. Unless RC9 was briefly published as next and then changed to canary, but you've managed to install it in that window.

Let's not nitpick in this, I am sure it was just an honest mistake and RC10 will be just fine :)

[jaredpalmer]

RC9 was a test and isn't stable

[jaredpalmer]

I wonder if switching to schema.validateAt impacted isValid behavior. Hmmm...

[danielkcz]

@jaredpalmer It's probably better to be releasing tests with a different ID than RC ;)

Can you at least point out to some branch or PR which is RC9 about? Hard to track what got broken otherwise.

[jaredpalmer]

It’s the debounce pr but I don’t think it built properly tbh

[jaredpalmer]

Try rc10

[danielkcz]

@jaredpalmer One essential problem with validateAt, it requires a schema to contain every possible field otherwise it fails.

Error: The schema does not contain the path: ingredients. (failed at: undefined which is a type: "object")

It's a major pain for big forms to be forcing full schema when only a couple of fields need to be actually validated. There is a TypeScript to tackle typos and stuff.

[Satyam]

Same behavior in rc.10 as with rc.9, except that rc.10 can now be loaded successfully in CodeSandbox: https://codesandbox.io/s/mystifying-leaf-j4hc6. The submit button gets enabled as soon as you type something in the first field, even though both are mandatory.
As long as the second one remains untouched, it doesn't validate it. If you type something into the second field and then backspace so as to empty it, it will disable the submit button.

[jaredpalmer]

@FredyC @Satyam 100% confirmed. This is my bad. I thought we could get some perf gains with this strategy (#1578), but now I see that it messses with isValid. I think we should revert it, and then update/rewrite the debounce PR (#1526)

[danielkcz]

@jaredpalmer I wonder how did you solve the #1654 (comment)? Looking at current master, the validateAt is still used there so it means it will crash when some field is missing from schema ...

formik/src/Formik.tsx

Line 205 in dce8d31

? schema.validateAt(field, values)