useFormik vs Formik

[FranciscoG]

The docs for useFormik make it seem like I should not be using useFormik, or that it should only be used in limited amount of use cases.

I personally prefer using useFormik for all of my forms because my components look cleaner (the render prop format of Formik adds too much ugly nesting) and I don't use any of the context, Field, FieldArray, etc things.

Is there a strong reason for me to be using the Formik component over useFormik hook? It seems to be working just fine for my use case but I just wanted to make sure I wasn't missing anything that using the component might gain me.

[FranciscoG]

nevermind, I answered my own question by finally having a reason that required context (using FieldArray) so I can see what it's useful. I still prefer to use useFormik for my simple forms because the code looks cleaner that way

[jaredpalmer]

Correct. useFormik() is great for simple forms, but you can't use any other context-powered components or hooks unless you pass the value returned by useFormik to FormikProvider (this is exactly what the Formik component does.

[onuralpbicer]

I just want to point out that you can use useFormik and have array form fields by doing the array operations yourself with setFieldValue, which is what I do in our forms. Yes, it does mean you have to do some grunt work that's already taken care of with FieldArray but in my opinion it's a worthwhile trade off for the must simpler syntax of the hook and the ability to access the values right there in the component body instead of as render props.

[KutnerUri]

I was really excited to use formik with hooks, and not the "ugly" syntax:

<Formik>(stuff) => (<div>...</div>)</Formik>

I find the "function as children syntax" worse because it's less readable, and mainly because it doesn't allow using Formik actions and state outside the JSX (in other hooks).

I was really expecting a syntax similar to this:

function LoginForm() {
  const [FormikLoginCtx, formikLoginProps] = useFormik({ ... });
  // or FormikLoginForm, etc

  // other hooks...

  return (
    <FormikLoginCtx>
      <Form>
        <h3>Hello, my friend. Stay awhile and listen!</h3>
        <div>name</div>
        <input .../>
      </Form>
    </FormikLoginCtx>
}

@jaredpalmer - what do you think?

[johnrom]

I don't agree with this syntax mostly because it's completely not backwards compatible, whereas it could be. I'd generally recommend using the somewhat standard [state, api] conventions. V3 wouldn't return state so it would simply return an API. formik. That said, I do think we can return the Context helper along with useFormik, like:

const formik = useFormik(...args);

return <formik.Context>
  <Form>
  </Form>
</formik.Context>

The only oddness comes from when someone needs to customize the Formik Context, like:

const formik = useFormik(...args);
const setFieldValue = useCallback((name, value, shouldValidate) => { 
  alert('updated field', name);
  formik.setFieldValue(name, value, shouldValidate);
}, [formik.setFieldValue]);
const overriddenFormik = useMemo(() => ({
  ...formik,
  setFieldValue,
}), [formik, setFieldValue]);

// FormikProvider was passed formik.Context which doesn't use the correct setFieldValue, so we should discard it. 
// that means the return type of useFormik and FormikContextType no longer match.
// which is probably fine?
return <FormikProvider value={overriddenFormik}>
  <Form />
</FormikProvider>

[KutnerUri]

I agree, we shouldn't break the api. using formik.context would be troublesome if we have a couple of forms in the same component, no?

I guess the syntax @rtm7777 suggested is good enough, just a lot of boilerplate.

[johnrom]

no, you could do

const registerForm = useFormik(...loginFormProps);
const loginForm = useFormik(...loginFormProps);

return <>
  <registerForm.Context>
    <Form />
  </registerForm.Context>
  <loginForm.Context>
    <Form />
  </loginForm.Context>
<>;

This wouldn't allow users to use nested context (already not possible), but it would allow for sibling context.

[rtm7777]

@KutnerUri you can import FormikProvider like:

import { FormikProvider } from 'formik'
const formik = useFormik({ })

<FormikProvider value={formik}>
  <Form />
</FormikProvider>

and I have no idea why we don't have it in documentation, I'll check if I have some free time for PR

export itself - https://github.com/formium/formik/blob/master/packages/formik/src/FormikContext.tsx#L10

[rtm7777]

Probably it's not documented because of this: #2746

[KutnerUri]

I know, I just think using a single hook for all would be cleaner

[onuralpbicer]

Well you can't set a context with a hook, yet at least, so you can't really have one hook to do that

…

On Sun, 24 Oct 2021, 19:04 Kutner JS, ***@***.***> wrote: I know, I just think using a single hook for all would be cleaner — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2851 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIZZ3MKSDTXM6F5QN2LZGZTUIO4ZJANCNFSM4TE7OOOQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[KutnerUri]

I was thinking of this syntax #2851 (comment), but I guess <FormikProvider> is ok.

[theonlydaleking]

My current approach is to use useFormik where possible as the default, and if not then I reach for <Formik>
I also prefer the cleaner syntax of the hook itself.