setSubmitting not working #1957

czaplej · 2019-10-29T17:03:21Z

🐛 Bug report

Current Behavior

setSubmitting method not changing FormikProps isSubmitting

Your environment

Software	Version(s)
Formik	2.0.3
React	16.10.2
TypeScript	3.6.4
Browser	Opera
npm/Yarn	1.19.1
Operating System	Windows10

warnellw · 2019-10-29T17:10:32Z

Experiencing a similar issue. isSubmitting is automatically getting set back to false in V2. According to the docs and the behavior in V1, isSubmitting must manually be set to false in the handler.

artemlatark · 2019-10-29T21:59:28Z

same problem

numToStr · 2019-10-30T07:58:29Z

I first thought that my form has some issues. After debugging I can say that setSubmitting is working but the issue is that isSubmitting set back to false after handleSubmit get executed.

czaplej · 2019-10-30T09:46:57Z

I first thought that my form has some issues. After debugging I can say that setSubmitting is working but the issue is that isSubmitting set back to false after handleSubmit get executed.

true, need to create for example promise or async and await for response submit,

Full example
https://codesandbox.io/s/formik-v2-template-9j5xz

srowe0091 · 2019-10-30T13:50:38Z

I'm also experiencing this issue. the docs say when you call handleSubmit(e) isSubmitting is set to true. This is indeed happening, but it is immediately getting set to false right after for some reason.

warnellw · 2019-10-30T14:18:05Z

It appears from the source that the submit handler is now expecting a Promise and Formik will set the isSubmitting state back to false when the promise resolves. If the submit handler is not a promise it resolves immediately.

Is this the new API of V2?

srowe0091 · 2019-10-30T14:59:37Z

I am now returning my promise handler and its now working, but I dont like this approach, because if you have chain promises, then isSubmitting will return false on the first promise, and basically the loading indicator will go away, but theres still more promises to fulfill afterwards. I'd prefer to manually reset isSubmitting, or add a flag to not auto update isSubmitting to false

paulkre · 2019-11-02T12:56:09Z

Can someone fix this or change the documentation, please? This is basic functionality for most forms and I went almost insane trying to figure out what was wrong 😅

Tigge · 2019-11-02T14:01:23Z

It's a bit unclear which behaviour is the intended one for version 2. If we can get some clarification I'd be happy to create a pull request.

kbi-daniel · 2019-11-02T18:44:21Z

It's a bit unclear which behaviour is the intended one for version 2. If we can get some clarification I'd be happy to create a pull request.

@Tigge For what it's worth, my vote would be to duplicate as closely as possible the behavior of Version 1, since I believe this would alleviate the need to refactor code to address this issue and in turn make migration to Version 2 as seamless as possible.

Just as an example, I have been using isSubmitting in my fields and buttons to disable functionality.
However, after migrating to Version 2, I now get a weird effect where my fields and buttons are made active for a split second before I have an opportunity to transition away. From a strictly selfish perspective, I'd hate to have to refactor all these forms in order to stay current with the latest version of Formik.

jaredpalmer · 2019-11-02T18:54:40Z

You should need to return a promise I thought. Manual setSubmitting calls should still work (mimic v1 behavior)

Tigge · 2019-11-02T19:03:09Z

@jaredpalmer: Previous behaviour is here https://github.com/jaredpalmer/formik/blob/version-1.5.8/src/Formik.tsx#L444. Nothing in formik touched the isSubmitting flag in version 1. You had to reset it yourself once you where done submitting. In the documentation this is also mentioned:

you call setSubmitting(false) in your handler to finish the cycle

In version 2 the behaviour is here https://github.com/jaredpalmer/formik/blob/master/src/Formik.tsx#L713, once your onSubmit function is done, resolved or rejected doesn't matter, formik will reset it to false for you.

I agree with @kbi-daniel that following version 1 behaviour would be nice - at least if you want to make the transitioning easier. If not - at least one of rejecting or resolving should keep the isSubmitting state.

Tigge · 2019-11-02T19:06:21Z

Also the onSubmit function is typed as onSubmit: (values: Values, formikHelpers: FormikHelpers<Values>) => void now.

alexisbg · 2019-11-02T20:15:58Z

And it's also very annoying when you expect an async result from a Redux state.

Please allow us to disable this new behaviour of isSubmitting and allow us to use setSubmitting again.

In version 2 the behaviour of isSubmitting was changed from having the user handle it's state after submitting to always resetting it to false after the onSubmit handler had returned (or it's promise). This reverts it back to the version 1 behaviour of not touching the isSubmitting state after the onSubmit handler has been called. Solves: jaredpalmer#1957

In version 2 the behaviour of isSubmitting was changed from having the user handle its state after submitting to always resetting it to false after the onSubmit handler had returned (or it's promise). This reverts it back to the version 1 behaviour of not touching the isSubmitting state after the onSubmit handler has been called. Solves: jaredpalmer#1957

Tigge · 2019-11-02T21:37:22Z

I've created a pull request (#1987) to revert the behaviour to how it functioned in version 1. If we want some other behaviour I'd be happy to adjust it or create a new pull request.

tphan18 · 2019-11-04T20:58:28Z

It will introduce a subtle bug that user can still click the button when you direct user to another page after the promise is fulfilled.

const onSubmit = (...) => {
  return submit(...).then(() => {
     Router.push(...) // The button is already enabled so user can click the button again. 
  })
}

In version 2 the behaviour of isSubmitting was changed from having the user handle its state after submitting to always resetting it to false after the onSubmit handler had returned (or it's promise). This reverts it back to the version 1 behaviour of not touching the isSubmitting state after the onSubmit handler has been called. Solves: jaredpalmer#1957

j0b0sapi3n · 2019-11-11T01:44:32Z

I'm seeing this issue in v2 as well. I see there's a PR to change it back to v1 behavior which I support.

srmasharad · 2019-11-13T11:13:58Z

Yeah I've also face the same issue in my latest project where I install the formik verison 2.0.3 where isSubmitting is not working and I switched back to the previous version 1.5.8 and it works for me.

vpartington · 2019-11-13T13:11:23Z

Same here. I've switched back to v1.5.8 for now. I hope the PR gets will get merged soon!

amr · 2019-11-18T20:01:34Z

This got me too. Perhaps a way of making both approaches (old + new) work is to check if the submit handler returns a promise, and only then trigger the new behavior.

I'm using redux saga to handle side effects so my method returns immediately after dispatching my actions and later on as part of my saga I'd setSubmitting to false

nperrier · 2019-11-18T22:51:12Z

This was confusing as well. I think the doc should at least be updated to indicate a Promise needs to be returned for it to work as indicated.

jaredpalmer · 2019-11-19T00:18:34Z

This got me too. Perhaps a way of making both approaches (old + new) work is to check if the submit handler returns a promise, and only then trigger the new behavior.

This is ideal and easy to implement. Can someone open a PR?

Tigge · 2019-11-19T06:03:10Z

This got me too. Perhaps a way of making both approaches (old + new) work is to check if the submit handler returns a promise, and only then trigger the new behavior.

This is ideal and easy to implement. Can someone open a PR?

@jaredpalmer but should there not be a way to keep the form in an unsubmitted state in the new promise version?

In version 2 the behaviour of isSubmitting was changed from having the user handle its state after submitting to always resetting it to false after the onSubmit handler had returned (or it's promise). This adds back to the version 1 behaviour of not touching the isSubmitting state after the onSubmit handler has been called if we don't return a promise in the onSubmit handler. Solves: jaredpalmer#1957

Tigge · 2019-11-20T08:29:32Z

I've updated my PR to enable both old + new behavior. The documentation is not updated yet there. However I don't think that is a good solution.

I can understand having isSubmitting as an internal state, only being true while the onSubmit handler runs. In that case there might be no need to have the setSubmitting function available either.

The use case for the old method was also to have it as a this form is submitted and should not be submittable again.

Either continue only with v2, allow it to be left in an isSubmitting state or just add an example on how to mimic that use case with react state or similar. And in either case, clarify how things really work in the documentation.

Either way (even if we do the dual version) I'll continue to update the PR.

In version 2 the behaviour of isSubmitting was changed from having the user handle its state after submitting to always resetting it to false after the onSubmit handler had returned (or it's promise). This adds back to the version 1 behaviour of not touching the isSubmitting state after the onSubmit handler has been called if we don't return a promise in the onSubmit handler. Solves: #1957

jaredpalmer · 2020-01-07T18:19:49Z

Fixed in 2.1

ahtashamabbasse · 2020-04-06T11:38:49Z

Fixed in 2.1

Causing issue in "formik": "^2.1.4"

WestonThayer · 2020-04-10T19:38:19Z

I can still repro this on 2.1.4 as well. See https://codesandbox.io/s/formik-codesandbox-template-6b1s9?file=/index.js

The current docs are accurate:

IMPORTANT: If onSubmit is async, then Formik will automatically set isSubmitting to false on your behalf once it has resolved. This means you do NOT need to call formikBag.setSubmitting(false) manually. However, if your onSubmit function is synchronous, then you need to call setSubmitting(false) on your own.

So either this issue should be re-opened, or we should accept the new behavior.

fuvizzo · 2020-06-03T21:25:18Z

i solved like this:

  const onSubmitClickHandler = (data, { setSubmitting }) => {
    const submit = async () => {
      const isAuthenticated = await props.signInWithEmailAndPassword(data);
      setSubmitting(false);
      if (isAuthenticated) history.push('/dashboard/menu-list');
    };
    submit();
  };

  return (    
      <Formik
        initialValues={initialValues}
        validationSchema={createSignInSchema(FormValidationErrors)}
        onSubmit={onSubmitClickHandler}
      >

I think it can be a workaround

itskarl · 2020-12-04T22:08:46Z

i solved like this:

  const onSubmitClickHandler = (data, { setSubmitting }) => {
    const submit = async () => {
      const isAuthenticated = await props.signInWithEmailAndPassword(data);
      setSubmitting(false);
      if (isAuthenticated) history.push('/dashboard/menu-list');
    };
    submit();
  };

  return (    
      <Formik
        initialValues={initialValues}
        validationSchema={createSignInSchema(FormValidationErrors)}
        onSubmit={onSubmitClickHandler}
      >

I think it can be a workaround

Thanks! This was the solution for me.

mohammadfayiztp · 2022-07-27T18:09:11Z

IF YOU USING REDUX STORE OR ANY ASYNC

FROM COMPONENT
////////////

 await new Promise((resolve, reject) => {
            dispatch(
              updateSalesOrder(
                {
                  ...data,
                  arrayDocuments: data.arrayDocuments.filter((x) => x.id === '').map((x) => getFileType(x))
                },
                resolve,
                reject
              )
            );
          })
            .then(() => {
              navigate(PATH_DASHBOARD.salesOrder.list);
            })
            .catch(() => {
              enqueueSnackbar('Something went wrong', {
                variant: 'erorr',
                action: (key) => (
                  <MIconButton size="small" onClick={() => closeSnackbar(key)}>
                    <Icon icon={closeFill} />
                  </MIconButton>
                )
              });
            });

FROM REDUX ACTION
////////////////

export const updateSalesOrder = (variables, resolve, reject) => async (dispatch) => {
  dispatch(loadingSalesOrder(UPDATE_SALES_ORDER_INIT, variables.salesOrderId));
  const resp = await UpdateRequest(variables);
  if (resp.status) {
    dispatch(successSalesOrder(UPDATE_SALES_ORDER_SUCCESS, resp.data));
    resolve();
  } else {
    dispatch(errorSalesOrder(UPDATE_SALES_ORDER_FAIL, { msg: resp.msg, variables }));
    reject();
  }
};

dlindahl mentioned this issue Nov 1, 2019

After submitting a form the isSubmitting property is automatically set back to false without calling setSubmitting() #1985

Open

Tigge mentioned this issue Nov 2, 2019

Change isSubmitting behaviour to mimic v1 #1987

Merged

willxy mentioned this issue Nov 8, 2019

[v2] isSubmitting resets to false too early. #1730

Open

nathonius mentioned this issue Nov 13, 2019

Inaccurate documentation regarding onSubmit. #1875

Closed

jaredpalmer closed this as completed Jan 7, 2020

This was referenced Jun 9, 2020

Feature/caes 958 fix secure message issues caesar-team/caesar-web-client#298

Merged

Feature/caes 958 fix secure message issues caesar-team/caesar-web-client#299

Merged

yuki24 mentioned this issue Jun 18, 2020

Fixes an issue where spinner does not show up on registration and bid+register forms artsy/force#5811

Merged

bodrovphone mentioned this issue Jul 31, 2021

Home page text update and Form refactoring bodrovphone/podelis-ui#58

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

setSubmitting not working #1957

setSubmitting not working #1957

czaplej commented Oct 29, 2019

warnellw commented Oct 29, 2019

artemlatark commented Oct 29, 2019

numToStr commented Oct 30, 2019

czaplej commented Oct 30, 2019 •

edited

srowe0091 commented Oct 30, 2019

warnellw commented Oct 30, 2019 •

edited

srowe0091 commented Oct 30, 2019

paulkre commented Nov 2, 2019

Tigge commented Nov 2, 2019

kbi-daniel commented Nov 2, 2019

jaredpalmer commented Nov 2, 2019

Tigge commented Nov 2, 2019 •

edited

Tigge commented Nov 2, 2019

alexisbg commented Nov 2, 2019 •

edited

Tigge commented Nov 2, 2019

tphan18 commented Nov 4, 2019

j0b0sapi3n commented Nov 11, 2019

srmasharad commented Nov 13, 2019 •

edited

vpartington commented Nov 13, 2019

amr commented Nov 18, 2019 •

edited

nperrier commented Nov 18, 2019

jaredpalmer commented Nov 19, 2019

Tigge commented Nov 19, 2019

Tigge commented Nov 20, 2019

jaredpalmer commented Jan 7, 2020

ahtashamabbasse commented Apr 6, 2020 •

edited

WestonThayer commented Apr 10, 2020

fuvizzo commented Jun 3, 2020

itskarl commented Dec 4, 2020

mohammadfayiztp commented Jul 27, 2022

setSubmitting not working #1957

setSubmitting not working #1957

Comments

czaplej commented Oct 29, 2019

🐛 Bug report

Current Behavior

Your environment

warnellw commented Oct 29, 2019

artemlatark commented Oct 29, 2019

numToStr commented Oct 30, 2019

czaplej commented Oct 30, 2019 • edited

srowe0091 commented Oct 30, 2019

warnellw commented Oct 30, 2019 • edited

srowe0091 commented Oct 30, 2019

paulkre commented Nov 2, 2019

Tigge commented Nov 2, 2019

kbi-daniel commented Nov 2, 2019

jaredpalmer commented Nov 2, 2019

Tigge commented Nov 2, 2019 • edited

Tigge commented Nov 2, 2019

alexisbg commented Nov 2, 2019 • edited

Tigge commented Nov 2, 2019

tphan18 commented Nov 4, 2019

j0b0sapi3n commented Nov 11, 2019

srmasharad commented Nov 13, 2019 • edited

vpartington commented Nov 13, 2019

amr commented Nov 18, 2019 • edited

nperrier commented Nov 18, 2019

jaredpalmer commented Nov 19, 2019

Tigge commented Nov 19, 2019

Tigge commented Nov 20, 2019

jaredpalmer commented Jan 7, 2020

ahtashamabbasse commented Apr 6, 2020 • edited

WestonThayer commented Apr 10, 2020

fuvizzo commented Jun 3, 2020

itskarl commented Dec 4, 2020

mohammadfayiztp commented Jul 27, 2022

IF YOU USING REDUX STORE OR ANY ASYNC

czaplej commented Oct 30, 2019 •

edited

warnellw commented Oct 30, 2019 •

edited

Tigge commented Nov 2, 2019 •

edited

alexisbg commented Nov 2, 2019 •

edited

srmasharad commented Nov 13, 2019 •

edited

amr commented Nov 18, 2019 •

edited

ahtashamabbasse commented Apr 6, 2020 •

edited