This post is not a battle royal or a straw man debate where one library stands victorious at the end. No, both Formik and Final Form do forms quite well and evidently with incredibly similar APIs. Their differences do not become apparent until you dive into the philosophies behind the development of each.
Checkout the source code and play with the app if you are curious.
rhoskal
/
formik-final-form
A little comparison between the two
Philosophy
Formik
The primary guiding principle behind Formik was to keep it simple. Consequently, this constraint resulted in no external state management, no subscriptions or observables and no re-inventing the wheel - it simply uses React. Therefore, if you have a problem understanding Formik then you probably have a problem understanding React.
Final Form
The creator of Final Form, Erik Rasmussen, also wrote Redux Form. Certain issues encountered in the aforementioned evidently influenced the two-part structure of Final Form: 1) a core written in Javascript to make it framework agnostic and 2) separate wrappers around Final Form’s subscription-based state management in your framework of choice such as react-final-form or vue-final-form.
Performance
Formik
Since Formik is built with React, it naturally takes advantage of builtin performance optimizations. Should you really need it (e.g. gigantic forms with > 70 fields), React’s shouldComponentUpdate lifecycle method can be indirectly used through the special <FastField /> component.
Final Form
Final Form is based on the Observer pattern, so observers can subscribe to receive updates for either form or field state changes. By default, like Formik, it subscribes to all form updates. It keeps state out of React, and then uses React context to hook in to the tree with react-final-form as previously mentioned.
It is not clear to me how subscription based performance enhancements compare with React’s reconciliation algorithm since I could not find any thoroughly detailed assessments. Therefore, I remain skeptical until proven otherwise.
Validation
Formik
Formik capitalizes on the powerful, and popular validation library Yup. Yup’s builder pattern makes building validation schemas a breeze and less error prone. You can also bring your own validation (BYOV) if Yup is not sufficient for your particular use case.
Final Form
Sadly, unlike Formik, Final Form subscribes to the BYOV philosophy. This is where I feel that the library missed an opportunity to save developers from themselves. Form libraries (in my opinion) are supposed to help with validation not skimp on it.
License
Formik → Apache 2.0
React Final Form → MIT
Bundle Size
Minified + gzipped:
Formik → ~15 kB
Final Form + React Final Form → ~9 kB
Redux Form → ~27 kB (for comparison)
Conclusion
As previously stated, the two libraries are quite similar so it really comes down to a simple question: which one does your your team prefer?
Top comments (2)
Yesterday I switched from formik to final form for one of my signup flows. I really like formik's integration with yup, but I end up writing way less code using final form. Someone put together a gist for using yup with RFF. I would always dread putting together a formik form, now with final form it's been a breeze. Maybe I just did not understand the "formik way" but so far final form has been MUCH easier, especially when using Material UI.
my company is actually doing the opposite we had issues with final form with our large dynamic forms (70+ fields) we had an issue with final form constantly re updating the fields. even after using subscriptions (very hard to integrate due to poor documentation)
subscriptions helped out dramatically but felt idiotic to have all these fields auto re render per type event.
Formiks documentation seems alot more friendlier and the overall concepts for setup between the two are the same so hopefully we have a better time with formik than final form