
The epiphany that sparked the creation of Final Form back in
[2017](https://erikras.com/blog/final-form-announcement), was that form state
has _nothing_ to do with frontend frameworks. It was always my intention that
Final Form should outlive React, the seemingly untoppleable ubiquitous
framework. Sure enough, it easiliy survived the transition to hooks, and people
built wrappers for Vue and Svelte, just as I'd hoped.

A few years ago, I got excited about a potential React killer in
[SolidJS](https://www.solidjs.com/) and wrote
[a proof of concept](https://erikras.com/blog/solid-final-form-poc) showing how
easily Final Form could be plugged into Solid. Indeed, it was delightfully easy.

I have not really been that excited about a "new framework" until this year when
[Dominic Gannaway](https://x.com/trueadm), who has recently become a colleague
of mine at Attio, released a _very_ pre-alpha proof of concept frontend
framework, called [Ripple](https://www.ripplejs.com/), where he has taken all
the best parts of React, Vue, Solid, and Svelte, and put them together into a
framework that should not feel _too_ foreign to the developers of those
frameworks. It's pretty clear that future frontend frameworks will all have some
sort of compile step; the days of "It's _just_ JavaScript!" are long gone; so
why not lean into the compiler for maximum developer experience?

> It's like Esperanto for frontend.

When playing with Ripple, every time I went to the docs with an "I wonder if it
supports...?" question, the answer was not just "Yes", but "Yes, and that API is
surprisingly nice!"

The API, however, is still in constant flux. The code I wrote a week ago working
on this no longer works, and likely what I'm showing today will not work next
week. **_THIS IS NOT PRODUCTION READY!_** The metaphor that comes to mind is a
polar bear walking on ice that has not yet solidified.

<img
  src="/images/polar-bear-on-ice.jpg"
  alt="Polar bear walking on ice"
  width={1024}
  height={1024}
/>

That said, let's look at what I've built!

## Proof of Concept

The primary component is one called `RippleFinalForm`, which creates a Final
Form instance, saves it to the context, and then renders a `<form>` component
with its `children` inside it. Then the inputs and error components are
connected to the Final Form instance via the `ref` syntax.

```typescript
export component App() {
  <RippleFinalForm {onSubmit} {validate}>
    <label>
      <input name="firstName" placeholder="First Name" {ref field} />
      <span {ref error("firstName")} />
    </label>
    <label>
      <input name="lastName" placeholder="Last Name" {ref field} />
      <span {ref error("lastName")} />
    </label>
    <label>
      <select name="favoriteColor" {ref field}>
        <option value="">{"Choose a color"}</option>
        <option value="#FF0000">{"Red"}</option>
        <option value="#00FF00">{"Green"}</option>
        <option value="#0000FF">{"Blue"}</option>
      </select>
      <span {ref error("favoriteColor")} />
    </label>
    <button type="submit">{"Submit"}</button>
    <Values />
  </RippleFinalForm>
}
```

Notice that a "component" is not a "function", and it doesn't "return" anything,
it just declares JSX. Also spot the `ref`s that allow attaching logic directly
to the DOM nodes.

I was able to implement a proof of concept that connects Ripple inputs to Final
Form in
[86 lines of code](https://stackblitz.com/edit/github-wqe28xcx?file=src%2FApp.ripple)
(Stackblitz).

### Cool, now what?

My instincts tell me that Ripple might actually be capable of toppling the React
Empire, but it's going to take a lot of work to get there.

**DO** check out [the docs](https://github.com/trueadm/ripple) and learn how
Ripple does things.

**DO** play around with it and submit issues and pull requests.

**DO NOT** (yet, in October 2025) use this anywhere near production.

Remember, form state – and much of frontend state – has nothing to do with UI
frameworks. Choose a headless solution and it just might outlast your UI
framework.

Thank you for reading.


🏁 Ripple Final Form


When I first wrote 🏁 Final Form back in
[2017](https://erikras.com/blog/final-form-announcement),
[Flow](https://flow.org/) and [TypeScript](https://www.typescriptlang.org/) were
exactly tied in the race to strongly type JavaScript.

At the time, I was just coming off of a switch from Angular to React. It was
really telling to me at the time that Google wasn't really using Angular in
their core user facing products, but Facebook was putting _all_ their chips on
React, dogfooding the crap out of it with their entire business on the line. And
Facebook was doing an _amazing_ job stewarding React in the Open Source
community. Choosing Flow, from Facebook, to build Final Form was a no-brainer.

In retrospect, we now know that I put all my money on the wrong dog in the race.

Shortly thereafter, Facebook stopped supporting Flow externally. It's my
understanding that those on the inside of Meta still use and love it.

## Withdrawl from Open Source

After getting laid off in March 2020 – remember anything else going on then? –
my career switched to jobs that needed more of my attention and also scratched
my React and JavaScript itches. I know they say that "[Software] is never
finished, merely abandoned", but... I think

> Final Form is more or less feature complete.

It handles a huge portion (> 95%) of form use cases, and those use cases haven't
changed in the eight years since I wrote it.

Nor will they.

Form state management will still be the same general shape of problem even when
our great-grandkids are filling out their Space Academy applications. Values,
validation, dirty, touched, submission errors, etc. The UI frameworks will
change, but the underlying form state won't. As far as I know, Final Form
remains one of only two framework agnostic form state solutions (the other is
the brand new [TanStack Form](https://tanstack.com/form), which solves the same
problems in a similar way).

### Complaints

People have been contacting me lately asking me to mark the library as dead or
at least update it to modern, say, React 19, standards. For years my response
has been, "Volunteers welcome!", but it turns out no one _really_ wants to help,
[certainly not a corporation](https://erikras.com/blog/open-source-sustainability).
In a recent
[response on Github](https://github.com/final-form/react-final-form/issues/1045#issuecomment-2853580304),
I said:

> It is true that:
>
> - I am no longer _actively_ maintaining FF.
> - An unattended `package.json` _will_ develop cobwebs.
>
> However, it's also true that:
>
> - The code still works.
> - IMHO, RFF is still the most ergonomic way to manage form state in React.
> - For the first time ever, I'm actually consuming RFF at my day job.
>
> I would love to hand the keys to the chapel over to a responsible young monk
> who will come in and sweep the floors and clear the cobwebs every so often.
> Any volunteers?

As per usual, this response received only crickets chirping. But the more I
thought about it, the more I liked my cobwebs metaphor.

<div style={{ textAlign: "center" }}>
  <img
    src="/images/cobwebs-church.jpg"
    alt="Cobwebs in a Church"
    width={1021}
    height={1019}
  />
</div>

If only there were a way to find junior developers that would work for little or
no money and keep working until all the linting and tests pass! Rather than an
intern to sweep the floors, what if there were like, some sort of...

_robot_ vacuum?!

## LLMs to the rescue!

It's 2025! We've all got an army of junior devs at our fingertips!

<div style={{ textAlign: "center" }}>
  <img
    src="/images/robot-monks-sweeping.jpg"
    alt="Robot monks sweeping"
    width={1024}
    height={1024}
  />
</div>

So I set about asking LLMs to convert Final Form from Flow to TypeScript, and it
went better than I could have expected. Of course, it helped that long ago I had
put in all of the legwork to have near 100% test coverage, so I could be certain
that the migration did not introduce any bugs.

Now that the code is modernized, I feel less apathy towards maintaining it, so I
hope to be more attentive in the future, though I am not promising anything.

In total precaution, I am bumping all the versions as if this were a breaking
change, even though I'm 99.9% sure that it isn't, unless you were relying on the
flow types, and in that case, you work for Meta and can build your own 🤬
internal form library.

| Library                             | Version                                                                                         |
| ----------------------------------- | ----------------------------------------------------------------------------------------------- |
| `final-form`                        | [`v5.0.0`](https://github.com/final-form/final-form/releases/tag/v5.0.0)                        |
| `final-form-focus`                  | [`v2.0.0`](https://github.com/final-form/final-form-focus/releases/tag/v2.0.0)                  |
| `final-form-calculate`              | [`v2.0.0`](https://github.com/final-form/final-form-calculate/releases/tag/v2.0.0)              |
| `final-form-arrays`                 | [`v4.0.0`](https://github.com/final-form/final-form-arrays/releases/tag/v4.0.0)                 |
| `final-form-submit-listener`        | [`v2.0.0`](https://github.com/final-form/final-form-submit-listener/releases/tag/v2.0.0)        |
| `react-final-form`                  | [`v7.0.0`](https://github.com/final-form/react-final-form/releases/tag/v7.0.0)                  |
| `react-final-form-arrays`           | [`v4.0.0`](https://github.com/final-form/react-final-form-arrays/releases/tag/v4.0.0)           |
| `react-final-form-arrays`           | [`v2.0.0`](https://github.com/final-form/react-final-form-listeners/releases/tag/v3.0.0)        |
| `react-final-form-html5-validation` | [`v2.0.0`](https://github.com/final-form/react-final-form-html5-validation/releases/tag/v2.0.0) |

❤️ Thank you for reading, and thank you all for bearing with me during these
years. 🫶


TypeScript

Posted in TypeScript