Kate:
Welcome to PodRocket. I'm Kate, the producer of PodRocket. With me hosting is Paul. Hi Paul. How's it going?

Paul:
Great. Thanks for having me again.

Kate:
Thanks for joining. And with us as a guest is Eric Rasmussen, creator of Final Form and Redux Form. Hello, Eric. How are you doing?

Erik:
Great to be here.

Kate:
Thanks for joining us. Yeah, so to get started, what is Final Form?

Erik:
Okay. So Final Form is a JavaScript's library for managing form state in your web application, although it could be used in mobile as well. So the problem it's trying to solve is how state flows through your form. We've all filled out forms. Common example is maybe booking airline tickets or something, now that we're starting to flag again. So you need to enter in information and the form needs to let the user know if what they're entering is valid. And there's so many things that go into making, keeping track of your form state. You would think it would just be the form values, but no, you need to, not only have validation, but maybe you need to add additional fields or something, depending on some other value that you entered. And it's just a fairly... It's more complex of a problem than it appears on the surface, let's say.

Erik:
And Final Form is a framework agnostic solution to that. And what I mean by that is it doesn't care if you're using React, or Vue, or Web Components, or just Vanilla JavaScript, it's going to help you manage your form state. It's going to handle all of those crazy edge cases for you in a way that at first glance you might think, "Oh, I can handle all this myself." But as your complexity grows, it probably handles all the complicated stuff that you didn't see coming. So it evolved... Well, it evolved as a second attempt at form state management after I made a previous attempt, but we can get into that.

Paul:
I'm sure being the creator of said framework, you become aware and exposed to all these issues you're talking about. Of me hopping into the React Deck, I say, "Oh, I'll make my form." You're the guy who has seen all the edge cases. I feel like you're talking really slowly looking up into the air like, "Oh God, these have people have no idea what they're about to step into if they do it themselves."

Erik:
Right. Exactly. So before Final Form, I wrote Redux Form, which it was around the time that React was very, very young. And if you look at the React docs, even to this day, seven years later or whatever, if you look at the React docs about how to maintain form state, they will tell you how to maintain the form state of a single input, and then they leave you there. Other frameworks, like Angular, which I had to use before React and was glad to leave, but they at least have more of an architecture for you to build your stuff around. But React is just like, "You're on your own. Good luck."

Erik:
And this is not true at all, but I like to joke that Facebook, their main product only has one input. Yeah. What is your status right now? But yeah. I've been using React as soon as they open-sourced it. And very early on, I was doing a side project that's required like seven inputs and it just got to be complicated just to have seven inputs. Right. And this was right around the time that Redux exploded.

Paul:
And that's the backend storage you can have for React application. In the front end it's like a key value store, sort of.

Erik:
Yes, sort of. This was soon after they released React and everyone discovered, "Man, maintaining state for my application is hard." Maybe a year and a half after they released React, the Facebook React team came out and said, "Hey, you should use this thing called... We're calling it Flux," as this way to maintain state where you have these different stores and you emit events, or actions or something, that alter the value in your store, and then you subscribe to your store. And they released this document with these drawings and said, "Yeah, do this." They didn't release any code. They just said, "This is how we're doing it in Facebook." And then everyone scrambled around to build their own implementation of what Facebook said was the way to maintain state. I built my own little implementation and so did everyone else, and there was this arms race in the ecosystem to see who could have the best Flux implementation.

Erik:
And then when Redux came along, it just, for those of us that had been thinking around Flux, it all just clicked that, "Oh, these aren't stores, these are reducers." But that was a very elegant solution to that problem at the time. And right around the time that I was. And I was in this ecosystem and watching all of these strategies fight it out. And when I needed to maintain more than three inputs for form data, I asked the people that were working on Redux, I said, "Hey, can I actually fire an action on every single key press to update form state?" And they said, "I don't see why not. That should work." And so I built a little reducer to maintain my seven field form state and it worked.

Erik:
It was quite lovely. And so I open sourced it and immediately it became clear that this was a problem that everyone was having. They couldn't figure out how to maintain their form state. And it became really, really popular. And as you suggested, I learned of all these different edge cases. Because, when I first built Redux Form I thought, "Well, of course. When you're developing your form, you're going to know how many fields you have, because you're filling out your shopping cart or whatever to check out." But no. Then people came and said, "Well, I need to press a button to add another field." I was like, "Add another field? You mean dynamic forms?" And so it was a very interesting few years of learning about the crazy wide, wide world of form requirements out there and adding. One mistake, looking back at Redux Form, was that I said yes to everything. Someone had a requirement and I was like, "I bet we could make it do that." And then again, and again, and again, and over. And iterating on that, the library grew to be really huge and-

Paul:
Unfocused maybe, because you were roping in all sorts of functionality, or is it unmaintainable? Was it unfocused unmaintainable, or how did it move?

Erik:
I wouldn't use those words. I would say that it just became... Someone would come to me and say, "Hey, this almost does what I need, but if we could just add this bullion setting, if you pass this setting, then it behaves in this other way." And I was like, "Yeah, sure. We could do that." And it just got to the point where there's so many different settings and so many different edge cases. Stuff that 1% or less than 1% of the consumers of the library need, and was it was handling those things. And so it got a little unwieldy and that was around the time when people started worrying about their bundle size of their libraries. Right. And Redux forum is a hefty library.

Erik:
Because, even if you're doing the simplest little type of form, you still have to download all the code to handle all of these crazy edge cases that you're probably never going to need. And that was one of the impulses for taking a step back and listening to all the feedback. Some people said... I don't know if this is still true, but some people were using Redux with other libraries, not just React, because in the end it's just some functions. And some people said, "Well, why do I have to use React if I want to use Redux Form? And then other people said, "Well, why do I need to use Redux? I'm using some other way to manage my application state, why do I need to have this application state management system just to manage my form state?"

Erik:
And those things were brought up to me, and I took a step back and rethought it and said, "What if there was just this pure JavaScript thing that you could keep your form state in?" And one of the other of complaints was, "When I change this bit of form state, my whole form has to rerender." And that was a time when React was, I guess, less performant than it is now. But also, if you're rerendering a whole bunch of stuff with your React application really quickly, like on every single key press, because forms are, I like to say it's a different kind of user interaction, because we're using a different device, we're not pointing and clicking with a mouse, we're typing as fast as we can type. And the form state changes that quickly.

Paul:
If I could interrupt for a sec, I'd really love to know a little bit about, 'cause we're getting into the differences of why you migrated from Redux Form into its predecessor and the details about this. I'd love to know what inherently makes this so difficult, because we're talking about a state management problem here, ultimately? We're talking about some tree of components that needs to be altered and processed in a creative way. That is tuned, as you're saying, to this new input form, and this is new input domain of typing. So if you could just maybe give us a little light bulb on our heads about why this is a problem, specifically in managing that state, in traversing that DOM tree, it would help me wrap my head around a little bit more as well.

Erik:
Not so much about traversing the DOM tree, but React has always recommended that you use what are called control inputs. And that means that in React, if you give an input a value, literally with a value prop, it will make sure that DOM node will always have whatever value you give it. So if you say, "Input value equals food," no matter how hard you bang on the keyboard you can't change that value, because React has taken control away from the DOM to manage that value state. An uncontrolled input in React is when you don't give it the value and you let the DOM node keep its own value. And then when you submit, you have to go and ask it for it. That's the way it was always done previously with jQuery and whatnot.

Erik:
Angular was a little different, because they had this two-way binding, where it wasn't really clear which value was the canonical one, if the DOM node was the one in charge or the framework. But with React, React would prefer that your DOM node, your DOM input not hold any state. They fight against the DOM in that aspect.

Paul:
They try to take as much control as possible.

Erik:
Correct. Right. And so that means that if you're going to provide a value, you also need to provide an on-change to then listen to the event, and then change the value somewhere in React land or somewhere in JavaScript. And then on the next render, give that field its value back. And also, having the value flow through your code means that you can do stuff like real time validation or real time formatting or something. You've all seen those inputs where you're typing in a date or something and the slashes appear between the month and the day or whatever. That sort of thing is enabled by having full control over what the value is.

Paul:
Is a downside of that having too many things fire off all the time and having the fire hose just open up on the React side.

Erik:
Well, exactly. The issue is depending on where you keep your state, worst case is you have to rerender your entire page on every key press. Because, with React, whenever your state changes in your component, the render function gets called again. Back in the old days, there was actually a function called render. And now we do most things with functional components, but where the whole function is your render function. And that could cause trouble. And like I was saying with the edge cases that I learned about, I would have people come to me and say, "I love your library." Everyone always starts off very nice in their complaints, which is great. I've heard that some open source containers don't have such good luck, but everyone with me has always been, "Hey, I love your library. But when I introduce my 300th input, things start to lag a little bit."

Erik:
And to little old me that started off with the seven inputs that seems like, "Wow. What are you doing in 300 inputs?" But I've seen some of these applications and it can get slow. So one of the other things I wanted to focus on with Final Form... Well, there was several things. Because Redux Forms bundle size got really crazy, I wanted to have Final Form be modular, so you could start off with just the bare core basics. And then if you needed to have an array of fields, there's another module that you can install and tack on, and you can build your own Lego solution that you need, as you need it. And thereby meaning that if you just need a really simple thing, your user doesn't have to download all of the code for all of the crazy stuff. But if you need to do crazy stuff, it can grow to manage that.

Erik:
And also, the Final Form allows you to pick and choose which bits of form states you care about, like if you don't want to rerender your form when the active field change changes. Sometimes you might want to do that if you want to show a tool tip or something next, or some sort of thing next to the field that you're in, you might need that. But if you don't, then you don't necessarily have to rerender when that changes. So Final Form has this concept of subscriptions. It's a little bit like GraphQL or things like that. Because, you can pick just the bits that you care about, and then your component will only be re rendered when those bits change.

Paul:
So does this have your own internal state machine that Final Form builds up to keep track of these things or is it a different paradigm in the way you built it?

Erik:
It manages all the bit states. It's just pure JavaScript. So there's Final Form and then there's React Final Form, which is this wrapper for React. And other people have built wrappers for other frameworks, like Vue and Web Components and stuff like that, which was my whole objective to begin with, was I want this to just manage your form state, and then whatever framework you want, you can make it fit that. My thought was this could outlive React. Whatever we're using after we stop using React, and we're using some other thing, we're still going to have form state, we're still going to need to know which field is this currently focused, and which field has errors, and then are we currently submitting, and do we have errors from the submit?

Erik:
And do we have asynchronous validation errors? Like sometimes you need to like go and check with the server while you're still filling out the form to see if a value is valid. All of this stuff, whatever we use after no one's using React anymore, we're still going to have all of these problems. And so it's an eternal thing. Whenever we're using our VR headsets and inputting our stuff in with gestures, we're still going to need to know which fields they're in now.

Erik:
What I didn't realized when I first wrote React Final Form was how quickly that was going to be tested, because I wrote React Final Form before they announced Hooks. And Hooks is a totally different way to manage your state in React. And it was really very, very nice how easy it was to migrate to Hooks. Because, with Final Form, whenever you need a new field, you just say, "Here's a field. I want to subscribe to these field state values." And then it gives you that. And then, when you subscribe to a field, it gives you back the unsubscribed function, which turns out to be in the exact API of useEffect. So it all just sort of clicked very, very nicely.

Paul:
It clicks well in my head and I've never used it before. So that kind of makes... It's only through useEffect that makes sense. It's like, "So you can subscribe. You unsubscribe when the life cycle's done."

Erik:
Right. Exactly. And if you need to listen to a different part, then you unsubscribe and resubscribe with a different subscription of what you're choosing to listen to.

Paul:
Sounds Fanta... Because, I've made one form in React and I did it all from scratch, and it was a pain, it was terrible. I'm not a front end developer either. I just play around, but it was really challenging to get that task done. So I'm very interested myself to check out. Now, Final Form. I should look at Final Form, correct, if I wanted to implement something, not Redux Form?

Erik:
Correct. Redux Form came first and you should not use that.

Paul:
And why not? What's the one or two centered reasons? I remember you saying it's big. It's a big library.

Erik:
Well, Redux is still very popular, but if you ask all the experts, "Hey, I'm starting an app. How should I manage my form state?" They're probably no... Not form state. "How should I manage my application state?" They're not going to say to go to Redux.

Paul:
Gotcha. Okay.

Erik:
Because, that was an elegant solution at the time, but there are better ways now.

Paul:
And everybody's moving towards smaller bundles anyways, like you said. The edge. Right. We got Versal doing their edge next deployments and all that. So you're trying to get things tiny.

Erik:
Right. Exactly. And also, Final Form was specifically built... One of the nice things about building one library and have it become really popular, and then building a second one, was that I literally had a list of all the use cases that I needed to provide for. I had a requirements document. And when I was building Final Form, I could almost build the tests for each of the different use cases before I implemented the code, and I could make sure that it handled everything that Redux Form handles. And it does, it handles all of them and more. If you go to the examples page of React Final Form, you'll see there's 30 different examples of all the different, weird, bizarre edge cases that it can handle. So yes, for sure. Go to React Final Form first.

Kate:
Awesome. Yeah, we'll include the links in our show notes as well. Link to Final Form. And I'm curious, you mentioned this on the React Podcast with Chantastic a while ago, but Redux Form, you had mentioned it gained a lot of adoption very quickly. Was there anything that you did particularly, or was it just timing, the timing was right?

Erik:
Yeah. The question I get sometimes is, "Hey, I just open-sourced something, how do I get people to use it?" And first of all, question if you really want people to use it. But yeah, it was a right place, right time. A couple of things went in my favor. Around that time, just as a hobby, but also what I was building side projects with was I put together a template for building React applications, using all the cool, modern technology of the time, like Webpack, and hot reloading, and server side rendering. This is before Next.JS came along, and this was around the time when they were called universal or isomorphic applications, because it was so cool that now we had node on the server that you could render your page before it gets to the browser.

Erik:
And I put together this template of all this cool new technology. And that was, I guess, maybe I did that before Redux Form. And that got... A lot of people were helping to con contribute to that and make it better. Webpack was super young at that time. But hot reloading was the coolest thing ever. And because I had this fairly popular... There were several of these, but for some reason mine was used and people were interested in it. But I included in it, "Hey, if you want a form solution, use Redux Form." And I think a lot of people adopted it as the first go-to way to manage form state. But also, there wasn't a lot of competition at that point about managing form state and React, and Redux Form was by far the most popular framework. But I waited a little too long, and around the time Render Props were becoming really popular, before I could release React Final Form, it came out and took everyone that was upset.

Erik:
Everyone that was using Redux form, because it was the best thing out there, but really wanted Render Props. But for technical reasons Redux Form can't do render props. And everyone was like... It was just a breath of fresh air for everyone and everyone went over to Formik. Formik, ever since, has been the most popular form library in React.

Erik:
Now there are... React Hook Form is gaining a lot of popularity. That's a library that took the dogma that all your components have to be controlled. Remember I talked about controlled abundance before. It took that dogma and was like, "Yeah, what if not?" And just ignored the best practices from Facebook, and turns out that you can do some amazing stuff with uncontrolled form inputs. And that also came around, obviously when everyone was like, "I want to do everything with Hooks." And so anyway, that's also a very popular one these days, and I'm very happy to not be the most popular form library. Although, I still think Final Form and React Final Form is an extremely elegant solution to this problem.

Paul:
Do you feel like it's easy to wrap your head around one or the other more for a newcomer who had hasn't dealt with forms before?

Erik:
That's a good question. And to be honest, I'm so deep in the form head space that I can't answer it.

Paul:
Fair enough. Fair enough. Yeah. Well, I was just going to ask, 'cause we don't have unlimited time tonight, when Kate sent me over some of your previous stuff, Eric, I came upon Centered, this app you're working on. So some of our time we have left, tell me about this workflow productivity application, because there's like 10,000 of them out there. I want to know why I should use Centered, why you started working on it. Those are my two big questions, but anything else we delve into, or Kate you have, I'd love to get into.

Erik:
Yeah, I would love to talk about Centered. It's gone through several iterations. I'm not the founder, I'm just an employee. I joined nine months ago, I guess, but it immediately clicked with me of why this was a good thing to exist. I describe Centered as a mindful productivity app. So what I mean by that is it makes you aware of what you're doing when you're at work, and you have to set out, "I'm going to get these two or three things done over the next hour and a half or whatever." And then it uses what's called the Pomodoro technique, which is working for a certain amount of time and then taking a short break, and then working for another bit and then taking another break.

Erik:
And there's quite a bit of evidence that shows that you're way more productive doing those, working with these breaks than if you just try and power through and get it all done, because your brain needs time to relax. And while you're on your break, getting a glass of water or going for a short walk or something, while you're on your break, your brain continues to work on the problem in a way that it doesn't, if you don't let it do that.

Paul:
It's like going to sleep and you're working on it?

Erik:
Yeah. It's like how we've all woken up in the morning and like, "Oh, I know the solution to this problem I was working on yesterday." It's a little bit like that. And so the way Centered works is you open it up and it's like a little to-do list. But that's super boring. In fact, literally all... I find it amusing that all the JS frameworks that you like... The first example of how to manage state is a to-do app, and now I'm building one. So you open it up and it says, "What do you want to get done?" And you type in a couple things and you estimate how long they're going to take, which is harder than it sounds, and then you say, "Okay, I'm going to start working now."

Erik:
And it opens up this little, what we call a mini player. And in the mini player, first of all, it plays music that doesn't have any lyrics and has a certain amount of beats per minute that has been shown to keep you concentrated. And there's, so much psychology behind Centered. And then, it shows you what you're working on now and you go about working on it. But if you get distracted, if you open up Twitter or, "I wonder what's up happening on Reddit," or whatever, Centered will notice, and our coach, Noah, will say, "Hey, do you really need to be checking Reddit right now?" And at first it's annoying, like, "Whatever mom." It's like someone is there nagging you, but it's actually what you needed at that moment, because you did say, "I'm going to get this thing done," and then you did end up on Reddit, and you do need to nudge.

Erik:
And the coach also comes on to tell, "Okay, it's about time to take a break." And also, whenever you complete a task, he's like, "Hey, good job. Give yourself a pat on the back. Well done." But the other really mind blowing psychological hack that Centered does, that seems so counterintuitive when you first hear it, is that you're encouraged to turn on your webcam when you're using Centered. And when you do that, you can see little tiny videos of other people using Centered right now. And there's no audio, you don't hear anything.

Erik:
But the effect is that you see other people sitting in front of their computers, getting worked done, and it's just like at the university library. Or if you have ever worked in a coffee shop or something, going to the coffee shop, opening your laptop and sitting down, and you see other people also at their laptops, it makes you more likely to get your work done, because, I don't know, you see other people working and you slightly feel seen, but not really. The other people at the coffee shop aren't looking at you, but it also means that you're not going to be watching Netflix at the coffee shop when pretending to type, right?

Erik:
These little psychological hacks are really, really powerful, and it really does help. It's helped me, and also everyone that works on Centered uses it all day long. Sometimes a bug will crop up and we will find it way before any users do, or any users report it, because we're dogfooding it all day long. And I really love working on it, because of all the apps that I've worked on in my career, it's the first one that I would be a customer of. It's one thing to be managing a backend database of inventory, blah, blah, blah. Super boring. And you can pay the bills building apps like that, but this is a thing that I want to exist.

Paul:
So it's something that you want to work on that's not open source. You've done it. You've found the pinnacle a lot of people are looking for.

Erik:
Yeah. And also, it's helping people in the world. Part of what I loved about open-source is helping people. The gratitude that I would receive when I implemented a feature that people had been begging for just felt intrinsically good. And Centered is making people more productive, and that's bettering society. So it's... I don't know. I'm proud of it.

Kate:
Can they see that you're podcasting right now?

Erik:
I have turned off the... I'm not in a Centered session at the moment. No. But good question.

Kate:
That's awesome.

Erik:
I'd like to encourage everyone to go to centered.app and try it out. It really is a game changer for literally... We're aiming at developers now, but literally anyone that has to sit in front of a computer and do stuff that isn't editing audio, I guess. But even for that, if you can turn off the audio, and it just focuses you. Anyway, I highly recommend it.

Kate:
Awesome. Yeah. We'll include that link as well. Is there anything else that you'd like to point our listeners to?

Erik:
No. Well, I'm giving a workshop at Reactathon in early May that's around forms and state machines. I'm a big fan of XState, the library to create state machines in JavaScript. And since arriving at Centered, I've refactored most of the code to using these state machines. And it is a really, really elegant solution. But if you Google XState, you'll find out all about that.

Kate:
Awesome. Yeah, we'll include that link as well. Eric, thank you so much. It's been a pleasure and we will see you around.

Erik:
Thank you. This has been great.

Kate:
Thanks for listening to PodRocket. You can find us @PodRocketpod on Twitter, and don't forget to subscribe, rate and review on Apple podcasts. Thanks.