make onSubmit/submitForm async

[devjones]

This PR enables chained promises with the submitForm imperative method. It will wait until any optional promises returned by a form's handleSubmit is resolved, before executing a chained promise. Such as:

submitForm().then(response=> {
  doSomethingAfterSubmit();
})

The async implementation in v2.0 canary does not support expected behavior of chainable promises since the promise in that function is never returned. Therefore in that implementation, doSomethingAfterSubmit() does not wait for resolution of a handleSubmit promise.

See below for the impact of return statements in Promise handler functions:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/then#Return_value

[flaviouk]

Hey, any updates on how this is going?

[Nemsae]

Noob question: how can I pull this branch?

[devjones]

@Nemsae Asa temporary stopgap until a fix is merged, you can clone my fork.

Then run

1. yarn link in the cloned repo
2. yarn link formik in your project folder.

This will force your project to use the forked version.

[Nemsae]

@devjones Appreciate the help but I have an issue using your forked repo. The file/folder structure between your repo that I run yarn link within differs greatly with the formik folder installed in node_modules with npm i --save formik.

Namely the index.js file in your fork is referencing formik.cjs.development.js which doesn't exist.

I get this error after running yarn link formik in my project folder:

Module not found: Error: Can't resolve './formik.cjs.development.js' in '/Users/Jcompsta/temp/Martin/formik'

I feel I may be missing a step.

[devjones]

@Nemsae You also need to build the package w/ yarn start. Follow Jared's guide here: https://github.com/jaredpalmer/formik/blob/master/.github/CONTRIBUTING.md

[jaredpalmer]

Fix conflicts por favor

[devjones]

@jaredpalmer Conflicts resolved.

[wdoug]

Why wrap this with Promise.resolve? Isn't the result the same without it?

[ryanburr]

This guarantees that a promise is returned. If this.props.onSubmit were to return void instead of a promise, this would ensure chaining.

[ryanburr]

This guarantees that a promise is returned. If this.props.onSubmit were to return void instead of a promise, this would ensure chaining.

[ryanburr]

Was this intentional to return void when there are validation errors? This would imply that consumer is checking the result of submitForm() before chaining to it

[slorber]

Agree we should rather harmonize on a single return type like Promise<Result | null>

[jaredpalmer]

Promise<Result | undefined>

[ryanburr]

Looks like the types for submitForm and onSubmit need to be updated.

https://github.com/devjones/formik/blob/master/src/types.tsx#L105
https://github.com/devjones/formik/blob/master/src/types.tsx#L202

[slorber]

@jaredpalmer do you plan to support this long awaited feature on 1.x?

That would be helpful as people can't necessarily migrate to hooks immediately and it's not yet a stable release (I'm doing Expo/RN in my case). I would be fine with a workaround until 2.x if you have one to share, but unfortunately I don't really see how to easily reproduce the behavior inside submitForm myself

[jaredpalmer]

@slorber planning to release v2 at React Europe

[slorber]

Great! As hooks are going in Expo 33 that should sync well

[ffMathy]

@jaredpalmer when is React Europe? Is it the one in May 2020? Because that's a crazy long wait for something like this.

[slorber]

@ffMathy as you can see there are RC's being published and actively worked on: https://github.com/jaredpalmer/formik/releases

[ffMathy]

@slorber ah very cool!

Is there an ETA on a release date?

[jaredpalmer]

Working pretty actively on v2. Things are getting stable. There are few more bits to tackle (#1371 , #1560, and #1555 are the big ones). After that we need to update the docs and write new examples.

[jaredpalmer]

@ffMathy Feel free to review active PRs and contribute. We could use the help!

[jaredpalmer]

This behavior is in v2 right now btw.

[andrewMuntyan]

Hi, all!

This behavior is in v2 right now btw.

@jaredpalmer have a question. I've updated to 2.0.1-rc.7 and trying to use this async submitForm.
It works just great in case form submission is completed without errors.
But in case I want to throw an error from my submitHandler it does not work properly.
Quick example:

// SomeContainer.tsx
submitHandler = async (
    values,
    { setErrors }: FormikHelpers<IMappedDefaultModelDataShape>,
  ) => {
    // ...some code here
    try {
      return await update(id, values);
    } catch (err) {
      throw Error(err);
    }
  };

  render() {
  return <Formik {...this.props} onSubmit={this.handleSubmit}></Formik>
 }

// SomeFieldRenderer.tsx
const onSaveButtonClick = async () => {
        const { submitForm } = props.formikActions;
        return submitForm()
          .then(promise => {
           // i'm always getting here
          })
          .catch((e: any) => {
           //cant get here
          });
      };

As I see from source code inside submitForm we handle catch case and just dispatch 'SUBMIT_FAILURE' in case submitHandler throws an error.

const submitForm = useEventCallback(() => {
    // ...some code here
    return validateFormWithHighPriority().then(
        // ...some code here
          return Promise.resolve(executeSubmit())
            .then(() => {
              if (!!isMounted.current) {
                dispatch({ type: 'SUBMIT_SUCCESS' });
              }
            })
            .catch(_errors => {
              if (!!isMounted.current) {
                dispatch({ type: 'SUBMIT_FAILURE' });
              }
             // I suppose we have to throw here in order to catch properly in my `onSaveButtonClick` method
            });
        // ...some code here
        return;
      }
    );
  }, [executeSubmit, validateFormWithHighPriority]);

Why do we not throwing error from cacth case? is it intentional?

[jaredpalmer]

@andrewMuntyan Not sure. Let's make a new issue with a repro.

[andrewMuntyan]

@andrewMuntyan Not sure. Let's make a new issue with a repro.

here #1636 I've created a new one

[jaredpalmer]

This is now in v2.