Formik: Formik vs Final Form

[pgrekovich]

What is the fundamental difference Formik from Final Form? Perhaps you need to add a table with a comparison of Formik vs Final Form (vs Redux Form)?

[klis87]

I used both libraries extensively, started with Formik, then tried FinalForm for another app due to its marketing of better potential performance due to optional subscriptions and ArrayField which wasnt available in Formik yet.

Right now, I am in the middle of refactoring really huge app back to Formik. Final form is library based on subscriptions and has React bindings as a separate lib while Formik is 1st class React citizen. Initially I thought it doesn't matter, but Final Form is not as Reacty as Formik - it has subscriptions, watchers, I encountered several race conditions bugs which I didnt understand, generally more magic which reminded me Angular times. With Formik I can feel control which React gives me again.

[vladshcherbin]

I also tried a number of form libraries in different projects:

• redux-form
• react-redux-form
• formik
• react-final-form

Working with formik was overall a nice experience, the only thing I didn't like - if you need a feature to be added (arrays, better custom components api, etc) / bug to be fixed / pr to be reviewed and merged, you can wait forever for it.

This is one of the reasons why I tested react-final-form the day I saw it mentioned in issues here. I used redux-form a lot and liked its api so it felt very familiar. It also had all features I missed in formik so I rewrote all components to use react-final-form. Since then I'm using it in all my projects and all issues/questions I had were solved in a couple of days so I'm very happy with the choice.

So, the point is: while you can compare technical things (redux inside, size, subscriptions, etc), you should also compare how much love, time and support is given to the library by its creator.

[jaredpalmer]

I understand the criticism and truly take it to heart. I hesitated to merge features like FieldArray early on and could have done a better job of communicating my daily thoughts on the subject and internal discussions with my team to everyone on GitHub. So that’s on me. Lesson learned.

The great news is that my team is expanding and will now have more resources dedicated to Formik starting in mid-April.

As for comparing Final Form to Formik...
Formik is built for React in React. It does not use subscriptions like Final Form does. This is a feature and an important one going forward as React async rolls out— if you have been following the React team on Twitter, they have discussed how subscriptions are only going to become more fragile and problematic down the road.

Phone’s about to die. Will post more later tonight.

[prichodko]

@jaredpalmer Have you been thinking about adding someone to the collaborators team? I would definitely love to help you maintain and push the library forward. We use Formik a lot at https://www.strv.com/, so I can even dedicate time during my regular work.

[pgrekovich]

@jaredpalmer I have no skepticism about the Formik, we chose it as the main tool for working with forms in our huge production application. Just for marketing it would be nice to explain to the users why it's better than the rest of the libraries :)
And I also wanted to create a issue(like @prichodko comment), I could help with maintaining. Now I could help with issues and mb PR's (and in mid-May with the implementation)

[payner35]

After spending some time on Final Form I have an issue with subscription/binding.. similar to @klis87

Its solid for basic forms.. but once you add the complexity of dynamically managing fields.. it's a struggle

Now exploring Formik.

[PatrickSannes]

@payner35 And what is your experience after 16 days?

[erikras]

Hi guys, author of Final Form here. I just discovered this thread today.

Formik is 1st class React citizen

I've heard this a few times. I'm not really sure how valid it is. React-Final-Form uses React context and state just like Formik does. The main difference is that the _actual canonical_ form state exists in another javascript object (kept in context), and _only_ the part of the form (or field) state that you subscribe to (where "subscribe to" == "optionally specify that you care about rerendering for"), so your entire form doesn't need to rerender whenever part of your form state changes (_if you don't want it to_).

For example, if you have a large form with many currently invalid fields, and your whole form component only cares if your invalid flag is true (e.g. to disable the submit button), and the user enters values in some of the fields which make the fields themselves no longer invalid, the form won't rerender until _all_ of the fields become valid, because it doesn't need to. That's the sort of optimization that React-Final-Form allows.

Formik is a fine library with slightly different design choices and trade-offs. Pick whichever one best fits best with your way of thinking.

[Andreyco]

@erikras love on point and honest opinion of “competing” lib's author

[jaredpalmer]

@erikras is correct. Formik’s state is kept inside of React which means that Formik is no different from any other React component with respect to reconciliation, testing, and optimization. This makes life easy since there is less magic. There is also no subscriptions or observables or reactivity with Formik. It’s just React.

As pointed out, Final Form keeps state out of React, and then uses React context to hook in to the tree with react-final-form. This means that with React Final Form you are using React components as wrappers around Final Form’s subscription-based state management.

Neither me nor my team, use subscriptions or observables, so Formik uses neither and never will under the hood.

As for performance, React has a lifecycle API that’s already purpose-built for blocking updates called shouldComponentUpdate. On gigantic forms (> 70 fields), it can make sense to wrap Formik’s Field component with a class that implements this so that you can save some renders. This is not unique to Formik, the same goes for any other React component. The reason that Formik renders on all updates by default is because React is really really fast by default. You also should not give AF about renders until it becomes a problem. At that point, you can optimize for perf using identical techniques that you already use—because everything stays in React.

Both @erikas and I are speaking at React Alicante in September about all this, so if you’re reading this thread you should definitely check that out.

[stale[bot]]

Hola! So here's the deal, between open source and my day job and life and what not, I have a lot to manage, so I use a GitHub bot to automate a few things here and there. This particular GitHub bot is going to mark this as stale because it has not had recent activity for a while. It will be closed if no further activity occurs in a few days. Do not take this personally--seriously--this is a completely automated action. If this is a mistake, just make a comment, DM me, send a carrier pidgeon, or a smoke signal.

[benjiwheeler]

One thought I think is worth adding is that final form has no outside dependencies besides react itself, while formik has a significant amount -- including the entire lodash library. It's hard to estimate the practical difference in size for each project, because that depends on what you're already using, but it may make formik 100kb+ in practice, while final form is below 10kb. I haven't used either yet, but that is weighing heavily on my decision.

[priyajeet]

@benjiwheeler The lodash imports are per method (and their deps) last I checked. Not the entire library.

import cloneDeep from 'lodash/cloneDeep';
import toPath from 'lodash/toPath';

[jaredpalmer]

Formik doesn’t bundle all of lodash. The imports are rewritten after the build step. Formik is fully treeshakable too

[baoduy]

I have also tried so may libraries related to the form management and eventually I end the trying with formik for my Production Application.

[awakened23]

As for comparing Final Form to Formik...
Formik is built for React in React. It does not use subscriptions like Final Form does. This is a feature and an important one going forward as React async rolls out— if you have been following the React team on Twitter, they have discussed how subscriptions are only going to become more fragile and problematic down the road.

@jaredpalmer , could you provide a link to that tweet or articles that talk about this in more detail?

[hosseintalebi]

I have created some forms with both Formik and React-Final-Form. If you're interested in comparing them side-by-side, take a look at here:
https://github.com/hosseintalebi/formik-vs-react-final-form

[iloveip]

@hosseintalebi Thank you very much! And what's your verdict?) Which library would you choose for your next project? (With complex dynamic and multi-step forms)

[hosseintalebi]

@iloveip Both of these libraries are great and the syntax is pretty similar. We found the documentation for RFF to be more complete and there are various examples for different kind of forms. Also, focus on error provided by RFF creates a great user experience. Votes on my team was tied between Fromik and RFF but we eventually decided to go for RFF. I don't think you would go wrong if you choose either.

[harobed]

I also tried a number of form libraries in different projects:

redux-form
react-redux-form
formik
react-final-form

@vladshcherbin have you tested https://react-hook-form.com ?

Related issue: https://github.com/react-hook-form/react-hook-form/issues/427

[vladshcherbin]

@harobed I've seen it, but haven't tried. When I tested all libraries in the list, hooks didn't exist, same as react-hook-form. Maybe I'll try it some day as it definitely looks interesting 😉

[wallymathieu]

There are some performance improvements that could be done to Formik. For instance move more of the logic into the internal reducer (i.e. for handleChange and ArrrayHelpers).

[johnrom]

@wallymathieu feel free to open an issue (if one doesn't exist already) or PR with either a suggested API or implementation. users need the ability to completely override array and change handling functionality, so we're always looking for ways to improve the balance between dev-friendliness and customizability.

[wallymathieu]

I've opened an issue for it: https://github.com/jaredpalmer/formik/issues/2221

[Wombbu]

Hi guys, author of Final Form here. I just discovered this thread today.

Formik is 1st class React citizen

I've heard this a few times. I'm not really sure how valid it is. React-Final-Form uses React context and state just like Formik does. The main difference is that the _actual canonical_ form state exists in another javascript object (kept in context), and _only_ the part of the form (or field) state that you subscribe to (where "subscribe to" == "optionally specify that you care about rerendering for"), so your entire form doesn't need to rerender whenever part of your form state changes (_if you don't want it to_).

For example, if you have a large form with many currently invalid fields, and your whole form component only cares if your invalid flag is true (e.g. to disable the submit button), and the user enters values in some of the fields which make the fields themselves no longer invalid, the form won't rerender until _all_ of the fields become valid, because it doesn't need to. That's the sort of optimization that React-Final-Form allows.

Formik is a fine library with slightly different design choices and trade-offs. Pick whichever one best fits best with your way of thinking.

@erikras thank you for your reply and all the great work you've been putting on final-form. I think the library is great and definitely very fast.

I have one question: The author of this package said the subscription based model final-form uses under the hood is going to be more fragile when React async rendering rolls out. What's your opinion on that?

[johnrom]

I think we've gotten some really cool responses here, and the information and it's quite an exciting read! However, I worry that a closed issue on Formik's repository isn't representative of a true debate, and maybe there is a better place for it in Reactiflux in one of the general discussion channels. I don't know if Reactiflux would accept something like this, but maybe even a battle of the forms Q&A session would be a fun request, and we can link to an archive of it from Formik's docs. As civil and fair as the discourse can be here, it'll still be biased by users that use Formik and not so much users that use Final Form.