🏁 Final Form – Announcement
The road to the checkered flag
Two and a half years ago, about a month after Dan Abramov’s unforgettable launch of Redux at React Europe 2015, I released a humble little library that managed form state in Redux, called Redux-Form, which, over the intervening period, has grown quite substantially in popularity.
As I write this in late 2017, Redux-Form has well over 8k stars on Github and 800k monthly downloads on NPM. By my recent calculations, based entirely on NPM download figures, about half of React projects use Redux, and about a quarter of those use Redux-Form, so about 11% of the 7 million projects that download React, also download Redux-Form.
With this popularity and usage has come a deluge of feedback. Everyone has had a slightly different use case and requested a slightly different behavior out of Redux-Form. I have done my best to accommodate these, and merge in pull requests for features that never would have occurred to me. I’ve done a lot of thinking about forms and form state management.
Problems with Redux-Form
Over these years, I have heard four primary complaints about Redux-Form. For some reason, unlike with most complaints, I have most heard these in person at conferences than on Twitter or Github or Stackoverflow. They are as follows, in no particular order, but with growing emoji angst:
- 🙁 It’s only for React?
“Redux works with Angular, et. al., it’s too bad that Redux-Form doesn’t.”
- 😢 I have to use Redux?
“I really need a form solution, but my project isn’t using Redux.” Also, everyone high up in the React community, including both inventors of Redux, say that Redux is not the best place to keep form data. Oops.
- 😖 I can’t use inline render functions?
“Why does my input lose focus on first keypress?” Well, it’s because Redux has
asynchronously updated both your input and the surrounding form component
(because now dirty === true), and because your inline render function is !==
the previous one, blah blah blah 😢
- 😭 It’s over 26k gzipped? No way!
“Bundle size, bro. I’m watching my weight.”
Premature Optimization
As v5 of Redux-Form became very popular, the biggest complaint I had was that
it was slow. The theory behind why was that it was rerendering the entire form
on every single keypress, since the values were provided to the form
component.
In early 2016, I solved this, by completely rewriting it from scratch, in what
became v6, creating a <Field/> component, which only updated when its
state changed, but did not update when another field’s state changed. This
complicated matters greatly, because now the whole <Form/> only received a few
select form-wide props, so the people that needed more information had to
connect() with a
suite of selectors to get
other form state that was no longer provided by default.
It is entirely possible that the fear of rerendering the entire form drummed
into me by the complaints that lead to Redux-Form v6 is unfounded, but,
whether or not the user notices it, it must be true that rerendering parts of
your tree needlessly is going to be slower than avoiding it. I decided that my
next form solution should have built-in “only rerender if you need to” logic,
which most people will never need, but that will allow fine tuning of complex
forms.
Solution
Some time in early 2017, I had the idea to create a “form state management engine” that was totally independent of React or Redux, just pure javascript. My first attempt was using Immutable.js, leveraging its power for fast “has this whole tree changed?” checks. I was about halfway done with it in May, when I mentioned it to fellow form library author, David Khourshid 🎹. His reaction to involving Immutable.js (15.3k gzipped) was negative, and it made me rethink my approach; could I do it without the help of any third party libraries? In August, during an offline vacation, I began coding a dependency-free form management library.
Going with the Flow
Normally I would build a library from the inside out, from the core to the public API, but this time, I defined the API first, even writing some tests, before implementing the core functionality. By strongly typing my API with Flow, I was able to catch bugs and ensure that the internals were satisfying the contracts of the API. It felt a little like pair programming with an annoying partner that was constantly saying, “Well actually, that’s supposed to return a string!”, but in a good way! Flow is awesome. 😍
Clogged Namespace
Before I get to the finish line of this post, I’d like to talk about the process of choosing library names. I probably tried a hundred different names involving the word “form” before finding one that was not taken already on NPM. So many of them are rotten unused/unfinished/undocumented libraries that have not been updated in a long time, and others are just empty namespace squatters — a tactic I was forced to resort to in reserving the name of my library until launch. I guess it was inevitable that a good NPM library name would become as hard to acquire as a good .com domain, but it’s still frustrating.
Speaking of namespace...Emojispace! After seeing the emoji branding succcesses of popular 2017 libraries Styled Components 💅, Glamorous 💄, and Downshift 🏎️, I decided that my library needed an emoji to go with it. I have been very nervous that someone might steal the one I chose (months ago) before launch, which has been very motivating!
Okay, now on to the announcement…..
🏁 Final Form
Today I am launching a new form library, called 🏁 Final Form. It’s based on the Observer pattern, so observers can subscribe to receive updates for either form or field state changes. Each observer must explicitly define which parts of the state they want to be notified about, and they will only be called when the parts they have subscribed to have been changed.
It has zero dependencies, is framework agnostic, and weighs in at 💥 3.5k gzipped 💥.
🏁 React Final Form
Of course it had to come with a companion library, 🏁 React Final Form, which is a thin wrapper around 🏁 Final Form that allows it to be used in React. And when I say thin… it weighs in at 💥 2.2k gzipped 💥, for a combined weight of 5.7k gzipped. It has no dependencies, and only two peer dependencies: 🏁 Final Form and React…..as the name would suggest 🙄.
Problems with Redux-Form: ✅ Solved!
- 🙂 Is it only for React?
Nope! There’s nothing stopping anyone from implementing a 🏁 Final Form wrapper in Angular, Ember, Vue, Preact, Elm, ReasonML, TheNextHotness™, etc.
- 😊 Do I have to use Redux?
Nope! State is canonically kept inside the 🏁 Final Form instance, and the React
components know when to rerender by calling setState() when they are notified
of a state change.
- 😀 Can I use inline render functions?
Of course you can! It’s almost 2018, for Pete Hunt’s sake! And to paraphrase a prominant thoughtleader of the React community:
“OMG!! Render functions! RENDER FUNCTION ALL THE THINGS!!!11one11"
–– Michael Jackson
Both the <Form/> and <Field/> components use the three ways of rendering
that I have humbly stolen from the awesome rival library,
Formik, by
Jared Palmer. Brilliant idea. You can either
pass a component, a render prop, or a render function to the children prop
(see docs).
- 😍 It’s only 5.7k gzipped? 21% the size of Redux-Form? AWESOME!
Lean and mean. 😎
What does it look like?
People familiar with the Redux-Form syntax should feel right at home, in fact many custom component libraries that have been adapted for Redux-Form should Just Work™ in 🏁 React Final Form. I will eventually write a Migration Guide, but I haven’t gotten around to that yet.
August 2019 Update: Migration Guide!
Roadmap
🏁 Final Form is not yet up to feature parity with Redux-Form. For example, at
launch, it’s missing the concept of <FieldArray/> to edit an array of values
(EDIT: <FieldArray/> functionality
released 7 days after this post
and <Fields/> to edit several fields in a single component. Nor does it have
some of the more esoteric features such as autofill. I plan on being a little
more willing to say, “No, I will not implement your specific feature,” with this
library, to minimize its complexity and surface area. I suspect that most edge
cases that previously required a new Redux action could be managed within React
state.
I very much look forward to working with others who want to wrap 🏁 Final Form into another view framework, or even other implementations of 🏁React Final Form. One suggestion: get in early if you want to be the dominant library (see first paragraph).
Conclusion
I cannot wait to get feedback from the community; I have learned so much from you all in my years with Redux Form. ❤️
I do plan on continuing to maintain Redux Form. If you’ve built a huge enterprise application on top of Redux Form, don’t worry; I’m not going anywhere. But maybe you could try out 🏁 Final Form on the next form page you build?
🙏 Thanks for reading. Go install it, star it, and give it a try! 🎉