What's the deal with the recommendation to use some library for managing forms? I've been working with React almost since its initial release and I've built some pretty complex forms... yet form libraries remain the one thing I've never really seen a need for.
At the very least, using something like formik shouldn't be a necessity. There should be some qualifier that it's only really needed for very complex forms. Or am I missing something?
I'll counter this by saying making forums is my least favorite thing to do in React.
Doing it by hand involves a ton of repetitive work.
Each form input needs to have its input validated client side (immediate errors), needs to have error messages from server side validation, needs to be accessible, needs to work across all browsers, any sort of drop downs from an input need to have proper a z-index, and state, so much state to track.
Doing it in vanilla Redux just sucks, and it is super easy to completely kill performance. Behold the number is sites that have a non-trivial delay when typing individual characters into a form.
(I've seen input delays on sites approach 500ms per character!)
(Of course 90% of this goes away by letting the browser handle forms, and accepting page refresh on submit, but if you want to go SPA...)
One of my larger regrets from my last project is not just learning a form library, it would've saved me literally weeks of work.
Although that entire site is a worst case, it is 3 giant forms each with over a dozens inputs varying from plain text to numeric to date-time to an image uploader and gallery manager.
Basically the best case scenario for "I should've learned a 3rd party library".
I don't think this is really a counter if you're talking about "3 giant forms each with over a dozens inputs." Yeah that sounds like a good use case to learn a library.
I guess my larger point that might not have been emphasized well enough is that recommending using a form library for _any_ form seems misguided.
I use redux-form and really enjoy it. A modern form UI has a lot of considerations that classic html/css forms do not:
* The concept of pristine/untouched inputs
* Basic and custom validations
* Resetting forms to various states
* Prepopulating data based on an API response
* Dynamically creating inputs based on UI states.
* Normalizing data upon input or submit
* Creating wizard/multi-step forms
All those implemented in Vanilla JS or in a React component can get messy. Is redux-form or any form library absolutely necessary, nope, but they sure do help.
At one place I was stuck with some React form library (can't remember the name but wouldn't shame either), as well as being stuck on a version of React Router that categorically refused to support some of the features earlier versions used to have.
I tried patching the form lib to update it from React 0.14.1 or whatever we were on way back then, to the new React 16 hotness. I eventually gave up because the code was so generic that I had to patch use-cases I'd never even thought of (good old feature creep).
Meanwhile, our home-grown forms using plain-JS, hooking into graphql, pretty much did the job with only simple abstractions. The same was to be said for the SVG-based clip-path polyfill I wrote to support IE. I had no problem writing a basic, self-contained component for that.
Most of those form use-cases are quite trivial implementations IMO and the complexity comes from working around the dependency's limited API rather than the browser itself.
Don't overthink it. Native HTML5 elements come with form validation and even a way to serialize (!) and submit form data w/ action and method attributes. (To implement the same as React components would be a 3 month project coming with a 1 GiB node_modules dir.) The only time you have to add JS bloat is for date pickers and time pickers which aren't supported on Safari yet (and you can user agent sniff for this).
Blows my mind why some people choose to adopt megabytes of dependencies when you can just write a few HTML tags and have it executed by the browser's C++ engine instead of some JavaScript nightmare.
People need way more validations than html5 elements can provide.
They need CC number validation. Validations that depend on the content of sibling elements. And they need it to display in custom ways like internationalized or whatever.
Attach event listeners and handle those parts with JS. For internationalization, template on the server side, sending a different bundle for user agents in different countries. CSS is enough to fill the gaps with other internationalization concerns like rtl.
The platform provides enough to do forms. It's one of the few things the web is good at. It has been around for ages and works. I mean, what I'm using to type this is a plain HTML form. It doesn't need a massive JavaScript framework that heats up my CPU on every keystroke.
> form libraries remain the one thing I've never really seen a need for
I felt this way too, until I used Ant Design's form component (which uses rc-form under the hood).
Form libraries take care of validation for you, allow you to specify an initialValues prop, and give you a handleFinish={values => ...} prop so it's easy to run your own API call when the user clicks "Submit".
Plus, Formik lets you model the form values using a TypeScript interface which I like.
To me, Formik provides several advantages over not using a form library, and no disadvantages except a small learning curve, so that's why I recommend it.
You certainly do not need to use a form library, but it does make it easier to deal with complicated issues such as render counts. I built a thin wrapper around material-ui and react final form (what I would suggest over formik) [1] and a little demo [2] that visually demonstrates this.
At the very least, using something like formik shouldn't be a necessity. There should be some qualifier that it's only really needed for very complex forms. Or am I missing something?