Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Formik vs Final Form #533

Closed
pgrekovich opened this issue Mar 24, 2018 · 15 comments

Comments

Projects
None yet
@pgrekovich
Copy link

commented Mar 24, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Mar 24, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Mar 27, 2018

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

This comment has been minimized.

Copy link
Owner

commented Mar 27, 2018

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

This comment has been minimized.

Copy link
Collaborator

commented Mar 28, 2018

@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

This comment has been minimized.

Copy link
Author

commented Mar 28, 2018

@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

This comment has been minimized.

Copy link

commented Jun 19, 2018

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

This comment has been minimized.

Copy link

commented Jul 5, 2018

@payner35 And what is your experience after 16 days?

@erikras

This comment has been minimized.

Copy link

commented Jul 10, 2018

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

This comment has been minimized.

Copy link
Collaborator

commented Jul 10, 2018

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

@jaredpalmer

This comment has been minimized.

Copy link
Owner

commented Jul 11, 2018

@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

This comment has been minimized.

Copy link

commented Sep 9, 2018

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.

@stale stale bot added the stale label Sep 9, 2018

@jaredpalmer jaredpalmer closed this Sep 9, 2018

@benjiwheeler

This comment has been minimized.

Copy link

commented Apr 17, 2019

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

This comment has been minimized.

Copy link

commented Apr 22, 2019

@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

This comment has been minimized.

Copy link
Owner

commented Apr 23, 2019

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

@baoduy

This comment has been minimized.

Copy link

commented Apr 30, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.