What should the default form library be in Blitz apps?

[flybayer]

Now that we decide to include user auth as part of new Blitz apps, we need to also include a default form library because we'll have multiple forms by default.

The top options are formik, react-final-form, and react-hook-form

Formik

Formik used to be my default form library of choice until I realized it has very bad perf problems for anything beyond very simple forms. There's a rummer that it's being converted to use subscriptions (like react-final-form), but 🤷

So I think our decision should be between react-final-form and react-hook-form

React-final-form

React-final-form has been my default for awhile now. I've used it on multiple projects with great success. It's super robust, blazing fast, and extremely powerful, including a really nice plugin system for things like persisting form state to local storage.

Our auth example app currently uses react-hook-form, so you can see it in use.

React-hook-form

I've never use react-hook-form on a full project, but I did convert the auth example app to use react-hook-form.

See the code diff between react-hook-form and react-final-form in the auth example.

The diff between react-final-form and react-hook-form is mostly trivial. A few things are different, but not much. That said, I really do prefer the API of react-final-form and think it's the best default option for Blitz.

Keep in mind, that we can always re-evaluate this later, and once we have recipes we can add a prompt that allows people to choose different options during new app creation.

[goldo]

i’m in favor of react hook form (vs final forms cause I dont like formik), not by much but I think the API is simpler: there is no render props which I find harder to deal with, specially for juniors, hooks are easier, they are more readable/understandable quickly, the docs are great, and for 95% of use cases it will do the job

[flybayer]

Have you used react-final-form? By the way, there is only one top level render prop with final-form which also provides the form context. They are both mostly hooked based.

[merelinguist]

I’ve used neither (only used Formik) but from the looks of it I think I agree with @goldo. The hooks api looks slightly better and more understandable to me. That said, I have no hugely strong feelings one way or the other.

[merelinguist]

Okay that said the wrangling of the error in the hook-form example is pretty gross so I think my vote might be for final form :)

[toddgeist]

I am not a fan of Render Props.

I don't know much about final-form, except that it was originally written to be Framework agnostic. I don't think that is a value that Blitz cares about. I would see it as a down-vote.

I have been using react-hook-form and I quite like it. It's only a year old, and is a react hooks FIRST approach to forms. Lots of updates, low open issue count. Very good docs. Also has Dev Tools

• Form Builder - https://react-hook-form.com/form-builder
• debugging validation helper - https://react-hook-form.com/dev-tools

Therefor react-hook-form gets my vote :-)

[flybayer]

Did you look at the diff? There is only one top level render prop with final-form which doubles as the context provider. Everything else is hooks.

[toddgeist]

Your points below on the need for a Controller are well taken. If we are going to need Render Props anyway then I can make do with final form.

I do find them very difficult to read when they are written in-line, but if the Form Component is declared separately it is better.

[MrLeebo]

My vote would be react-hook-form. I haven't used react-final-form much, but I was a heavy user of redux-form, which a lot of the API is derived from, and it was probably the most significant hurdle when we brought non-React devs to work on our React components. We had to develop a lot of "tribal knowledge" about the correct way to structure forms to fit our needs and avoid issues with state updates happening in the wrong order or calculating the wrong final state. Looking at the FAQ I'm seeing questions/answers that remind me of the kinds of "tribal rules" that we had to come up with for redux-form.

Plus the appearance of a useField() hook in the API turns me off because that encourages users to put field state at the form level which will lead to performance issues for forms with more than a trivial number of fields.

[flybayer]

What part of the diff is like redux-form? (I don't see anything based on the redux-form docs — but never used redux-form). The FAQ section looks like it's only for people who have used redux-form, so I'm struggling to see the comparison here :)

Plus the appearance of a useField() hook in the API turns me off because that encourages users to put field state at the form level which will lead to performance issues for forms with more than a trivial number of fields.

Can you elaborate?

[MrLeebo]

// 🚫
function Foo() {
  // entire component re-renders for keypress, focus, blur, etc of any field
  // I think people like to try to write their fields this way because it "feels" like
  // it's making good use of react patterns even though it isn't.
  const firstName = useField('firstName')
  const middleName = useField('middleName')
  const lastName = useField('lastName')
  const suffix = useField('suffix')

  return (
    <>
      <label>First Name: <input {...firstName.input} /></label>
      <label>Middle Name: <input {...middleName.input} /></label>
      <label>Last Name: <input {...lastName.input} /></label>
      <label>Suffix: <input {...suffix.input} /></label>
    </>
  )
}

// ✅
function Foo() {
  // Field component isolates the states
  return (
    <>
      <label>First Name: <Field name="firstName" component="input" /></label>
      <label>Middle Name: <Field name="middleName" component="input" /></label>
      <label>Last Name: <Field name="lastName" component="input" /></label>
      <label>Suffix: <Field name="suffix" component="input" /></label>
    </>    
  )
}

[MrLeebo]

Had a chance to use RHF and even though this discussion is moot because of recipes, it persuaded me to change my vote and that RHF wouldn't have been a great default choice anyway. It's APIs don't seem very declarative and that makes them unintuitive in relation to React's design principles, Internet Explorer support seems very spotty and requires you to load a totally different distributable (is it compatible with the primary dist? the authors aren't even sure!), and I think the "simple learning curve" aspect drops off quickly when you start dealing with controlled components or nested arrays/objects.

[johncantrell97]

I'll also toss a vote for react-hook-form. I've been using it in all my projects lately and it has been (mostly) a joy to use.

[flybayer]

Have you used react-final-form?

[flybayer]

One of the things that turns me off the most about hook-form is that as soon as you need a controlled component (and you will if your app is of any size or uses a lot of third party components) you have to use the alternative react-hook-form <Controller> component with a render prop. For example you have to do this to use react-select.

https://react-hook-form.com/get-started#IntegratingwithUIlibraries

import React from "react";
import Select from "react-select";
import { useForm, Controller } from "react-hook-form";
import MaterialUIInput from "@material-ui/core/Input";
import { Input as AntdInput } from "antd";

const App = () => {
  const { control, handleSubmit } = useForm();

  const onSubmit = data => {
    console.log(data)
  };

  return (
    <form onSubmit={handleSubmit(onSubmit)}>
      <Controller
        as={MaterialUIInput}
        name="firstName"
        control={control}
        defaultValue=""
      />
      <Controller
        as={AntdInput}
        name="lastName"
        control={control}
        defaultValue=""
      />
      <Controller
        name="iceCreamType"
        as={Select}
        options={[
          { value: "chocolate", label: "Chocolate" },
          { value: "strawberry", label: "Strawberry" },
          { value: "vanilla", label: "Vanilla" }
        ]}
        control={control}
        rules={{ required: true }}
      />
      <input type="submit" />
    </form>
  );
};

That means you have two different hook-form APIs you have to know and use. But with react-final-form, you use the same useField() API for everything. There's less api you have to learn, and less cognitive dissonance when switching between the different apis.

So either way, you'll likely have a render prop. I definitely agree the primary API shouldn't be a render prop, but looks like it's impossible to 100% avoid render props.

---

I think the whole dance to avoid controlled components by passing refs to everything just unnecessarily complicates everything, especially when a subscription implementation like final-form gives you the same high performance with controlled components.

An example of this is when you need to add your own ref to a component for doing imperative focus or something. Now instead of doing the normal ref={ref} thing you have to do this extra dance that is not intuitive:

  const { register, handleSubmit } = useForm();
  const firstNameRef = useRef();
  const onSubmit = data => console.log(data);

  return (
    <form onSubmit={handleSubmit(onSubmit)}>
      <input name="firstName" ref={(e) => {
        register(e)              // hook-form register
        firstNameRef.current = e // manually assign your ref
      }} />

---

Also hook-form has subtle UX things with validation that is sub-par. With hook-from you set the validation mode of onBlur on onChange with no in-between. But final-form does a mix here that is the best UX imo. It doesn't show an error until the first blur event, but after that it validates onChange.

So the optimal flow which you get with final-form is this:

1. Click email field
2. Enter invalid text
3. Click away
4. Error shows
5. Click email field and start typing invalid email
6. 👉 While typing, as soon as email is valid, the error goes away. (But hook-form leaves the error until you click away, so you don't know if it's valid without switching focus away)

[goldo]

I haven't got enough experience with hook-form I must admit, but in your example there is no renderProps fn ?

As I said, I wasn't strongly against final-forms either. But globally, I think blitz should go with the simpler option for entry level and basic usage, since It's not that difficult to remove a lib and add another one.

Also now that I think about what blitz does generate for you, I'm wrong: it would be a waste of time to rewrite all the code blitz could generate on a form. So.. maybe give the option for the user to choose which lib to use in the CLI ?

If not, and if you still in favor of final-forms, i'm ok with it

[rockymeza]

I agree 100% about the weird ref thing. The React way to use inputs is to have value/onChange and the ref thing makes it hard to incorporate third party inputs

[Zeko369]

I mostly worked with react-hook-form and it's been a pleasure to use. I think that the need to use render props (for the "default" way of using react-final-form) is a big turnoff for newer developers

[LoriKarikari]

I've only used formik and react-hook-form so I can't say much about react-final-form. It seems from the comments above that react-hook-form is the most popular choice and maybe we should go with that? Eventually, we can't please everyone but going with the most used library seems a safe bet as most people are familiar with it?

[flybayer]

Something else to keep in mind is that we aren't necessarily optimizing for beginners. I think we are optimizing for the long-term pit of success. In other words, when possible we want to minimize the situations where a year or so after starting, Blitz devs have to replace a part of the app that came by default with a new Blitz app.

react-hook-form is one these cases where it's guaranteed there will be users that have to switch to something more advanced that uses controlled components.

This default that we are deciding here is also what will be the "recommended" choice once we add multiple options to blitz new

[Zeko369]

You can get 'semi-controlled' inputs with RHF using setValue and getValue

[remidej]

react-hook-form has been my go-to solution for the past year. It's much nicer to use than Formik. It's very simple for small forms, but also provides APIs to have full control over your form. I especially like that they provide examples for many complex use cases.

I haven't tried react-final-form. As far as popularity goes, both are widely used, but react-hook-form seems to be getting more traction (see the chart)

[toddgeist]

I am changing my vote to react-final-form. I think @flybayer is right. We should NOT have a default that will not run out of gas as a project matures.

[alkamin]

I've used Formik, react-final-form, and react-hook-form. react-hook-form was a much nicer experience than the others. I found react-final-form to get unwieldy very quickly. I was hoping react-final-form to be an improvment over Formik but that was not the case for me. react-hook-form is now my go-to solution for forms as well.

[flybayer]

@alkamin that's interesting, thanks for sharing! I'm curious what exactly did you find was a nicer experience with react-hook-form?

[alkamin]

I found that others were able to grok react-hook-form code a lot easier than react-final-form. There's no doubt that rff is powerful, but the learning curve is pretty large IME. My feeling was that while RHF had a smaller API surface area and lacked some features that RFF had, it turns out that for our uses RHF was totally sufficient. I think probably for most blitz users it would also be sufficient.

Yay for recipes!

[flybayer]

Well, since recipes are now working we can launch with both react-hook-form and react-final-form as options! Debate resolved 😇

[goldo]

I think it's a good idea 👍 so.. which one will be the default one ? 😈

[flybayer]

You'll have to choose! So no default

[fraserdrops]

You'll have to choose! So no default

I'm a bit late to the party (I just saw #917 ) but personally I don't think having to choose a form library right away is the best experience. To me the beauty of blitz is being able to run blitz new and have a fullstack app ready to go with no fuss. I haven't used either of these libraries so I have no opinion about what I should use, and I would much rather blitz just start with one by default. For people who prefer a different library, blitz should make it really easy to change, but I still think there should be a default.

[flybayer]

@fmcintosh yeah that totally makes sense. I've marked react final form as "recommended", so hopefully that helps people who don't know.

I think this discussion thread has shown that there's enough people who do care about their form library that it would be detrimental to force them with a choice they don't want. :)