formik: Setting no validate or validationSchema clears out imperative error state on onBlur/onChange

Current Behavior

Whenever you setup a Formik form and supply no validate or validationSchema, but you call setErrors/setFieldError as if it’s coming from an API, it will clear out the entire errors object from Formik whenever you change or blur ANY field.

formik-validation2

Steps to Reproduce

See codesandbox for more info

Expected behavior

I would say whenever you apply no validate or validationSchema, it should only clear out the error of the field you touched, not the entire form.

Additional context

Note: The Formik version of 0.11.11 does not clear the errors object on change or blur at all (which to me seems a bit more reasonable, since you explicitly set the errors yourself and there’s not validation, so you’ll have to manually clear them as well).

Note: I haven’t tested if this behaviour also happens whenever you do have a validate or validationSchema setup.

CodeSandbox Link: https://codesandbox.io/s/pykpn4386m

Formik Version: 1.0.3
React Version: 16.3.2
TypeScript Version: -
Browser and Version: Chrome Version 68.0.3440.106 (Official Build) (64-bit)
OS: OS X 10.13.6
Node Version: -
Package Manager and Version: -

About this issue

Original URL
State: closed
Created 6 years ago
Reactions: 16
Comments: 31

Most upvoted comments

I don’t think this is stale. I am curious if this behaviour is intended or whether it’s a bug 🤔

inooid on Oct 21, 2018

So, for someone still finding this thread, you can just set validateOnBlur={false} and validateOnChange={false} on your Formik component

msnegurski on Oct 29, 2021

I get a similar issue when I try to setFieldError which I haven’t in validationSchema. So I can get this error, but when I’m editing another field, an errors object contains all of the errors except error from setFieldError

I guess this issue because

return promise
      .then((errors: FormikErrors<Values>) => {
        this.setState(prevState => {
          if (!isEqual(prevState.errors, errors)) {
            return { errors };
          }
          return null; // abort the update
        });
        return errors;
      })
      .catch(x => x);

Here prevState.errors and errors are different, and if they are different we return new errors object… Maybe I’m incorrect here…

@jaredpalmer , could you please help us here?

vtereshyn on Jan 29, 2019

I am experiencing the same problem and setting the third parameter “shouldValidate” on either setFieldTouched or setFieldError has not impact.

The setFieldError places the error in the error collection; however, it is removed again before the final re-rendering.

MDornian on Oct 26, 2018

Anyone managed to solve this?

bymoe on Oct 6, 2020

Hi @inooid Thanks for posting this issue, I’ve debug this and found an appropriate solution to fix this issue. You can use setStatus to manage the BE errors.

Before : 
      fieldErrors?.forEach((item, index) => {
          if (Object.keys(item).length) {
            Object.keys(item).forEach((obj) => {
              console.log("FORMIK", fourCparamsRef);
              fourCparamsRef.current.setFieldError(`colorEstimation[${index}].${obj}`, item[obj]);
            });
          }
        });

After : 

        fourCparamsRef.current.setStatus({ colorEstimation: fieldErrors });


input.js

      {status && <span className='error-text'>{status}</span>}

So Here we can use setStatus instead of setFiedError.

AminTaiTntra on Jul 4, 2023

@CalvinD3v honestly can’t remember what I did to solve this. There are some ideas listed above though 👍

inooid on Aug 19, 2022

@ImSolitude @val-samonte TBH I don’t really think anybody gonna handle this, because this was reproducible in early 1.0.3 Formik version, which was in alfa at that time.

And if I’m not mistaken it was fixed in 1.1 or some newer versions. So if you still use Formik 1.0.3 or similar alfa version maybe you should try to update it or if you still face this issue in newer versions of Formik maybe it will be more appropriate to open a new issue.

dev99problems on Oct 13, 2020

I think this needs to be reopened.

val-samonte on Oct 13, 2020