Enhancing Forms with React Server Components

My name is Aurora. I'm a web developer from Norway, and I work as a consultant in Oslo, and I'm building actively with React components in my project, and that's where I try to get my knowledge and make some examples to help teach other people about that.

How many people use React server components here? Okay, quite a lot. Wow, that's good, that's good. Nice.

I'm excited to be demoing a practical example of working with forms and server components here today, and I'm going to be coding something that is based on or inspired by a feature that I built in my current project. So let's get right to it.

So the setup here is an XGS app router course, and it's using Prisma as an ORM and a local database and Tailwind for CSS. I'm a huge Tailwind fan. And let's just go through the starting files here.

So since we're in the app router, everything is a server component by default, right? And that means that all of these components here are, wow, okay, are server components by default. And that means that I can actually make them async. So server components can be async, and I can actually asynchronously fetch data right inside the component itself.

And here I have a message box, and it's fetching messages from the database directly through Prisma. And then there is also a message display component here, or I'm mapping the messages to message display components. And here, all we need to do is just style based on whether the message is written by the user. So just a server component, nothing special here.

And there is also a message input, and that's this form here, and it doesn't do anything right now. It's just a form with a single input, and I'll just test it here. So nothing's going to happen.

So this is all server component, which means that there's no JS added to the client bundle for any of these components. And let's enhance this with React 19. The goal will be to make this interactive, while minimizing the JS on the client and reducing the front-end complexity. And let's begin by just making the form work. So I'm going to use React 19's extension of the form element to bind the action property to a function. This is we can do this with React 19 now.

And React 19 was just released like last week, two weeks ago, finally, after being RC for like half a year. So, whoo. Yeah, that's nice. Yeah.

Anyway, we can bind to a function here. So I'm going to bind to submit message and I'm going to create a server function. So I'll do it here in my data access layer. I'll just say submit message TS. And since I'm going to make a server function, I will be using the directive of React 19, use server. And what this means is that every function in this file will be callable as server code, but callable from the client. And we'll have a hidden API endpoint generated automatically. So we're going to export an async function here, which is the submit message, if I can spell function. That's a good thing if I can do a function. There we go. And this will take in a form data object of type form data. And what this means is that each field in this form would be submitted with its value inside the form data object. And we can use this to just insert into the database using Prisma, create a message where the data will be content here. I'll just get it from the form data. We'll type it as a string for now. And I also need a created by ID here. And that means that I somehow need to pass an additional argument to this server function. And there's a couple ways we can do this. We can do like a dot bind. That's one way. Or we can use a hidden input. So here I'm going to use a hidden input, bind it to the user ID, and I can just import this server function here. And now I can get this from the form data. There we go. And let's try to wrap this up here. And I have to add a bit of a disclaimer here because you don't really want to pass the user ID from the client side. That's just an example of how you can pass additional parameters when you do encounter that. So you would want some kind of server-side authentication setup. But this is OK for now. So let's try it out.

And say, hey, and then I'll just manually refresh the page here, and then it's been submitted to the database. But of course, I don't want to manually refresh the page. So I can call Next.js revalidate path with the root path to say that Next.js should purge the server component cache and regenerate everything on this path. So that when I now try again, I don't have to refresh. It's just there automatically.

So that's all I had to do to actually submit a form to the database on the server with the server function. And this is quite a lot simpler than using my onSubmit, prevent default, create an API route, blah, blah, blah, blah, blah. And actually, onSubmit wouldn't work before hydration has happened anyway. So we're getting a lot of benefits from this.

But one thing that happened is that when I submitted this message, I was, like, in this view here. And I couldn't actually see the new message right away. And we're going to fix that. So I'll head over to the message box. And I'll just replace this div here with an automatic scroller. And this component is a client component, because I actually need client-side JS, because I'm using an effect, an imitation observer to scroll to the bottom of the container when there is a new child inserted into the list. And this requires client-side JS. But since I'm passing in the content as a prop, in this case, the children prop, I can actually render server components inside this. I don't convert them to client components. So here, I'm mapping to message display. Let's just try it first. Let's say, scroll. So it's scrolling. It's working. But when I check inside the React DevTools, we can actually see, zoom this in a bit, that here I have the scroller as a normal React component, but all of these message display components are still server components. And this is a new feature in React DevTools. You can see which components are server components, which is pretty nice. So we're already doing an optimization there.

Okay. Let's get back to the message input, because we're submitting something from the client to the server, and we really should be validating this. So to do that, I will be getting a result from a message schema.

And this, well, we can just safely parse first. And I'll just move this object here. And I don't need to type these as strings anymore. And we can use the result to introduce.

The message schema is using Zod to, at runtime, validate that the schema or the object path is of a certain requirement. In this case, the content must be one character long, and the createdById must be a unique ID. And if this fails, I need to handle that somehow. And for now, I'll just do, if the result is not a success, we can throw a new error and just say invalid message data. There we go.

And to try this, I'll just comment out my client-side validation. And now, if I submit invalid message, which is, you know, zero characters, I will have this error thrown. And there's a bunch of ways to deal with errors. One of them can be by using an error boundary. So I can add an error boundary around the message input to catch this. And I'll do that in the message box. So I'll just add an error boundary here and wrap it around the message input. Yeah, the auto-import's not working. Let's just import the error boundary. There we go. From react-error-boundary. And now, if I have an invalid message, it will be caught nicely by this error boundary. And this is just a developer tool in that way. So that's nice.

But actually, I don't want to throw an error if the validation failed. I would rather return something. So instead of throwing an error here, I will just return a success false. And I'll return the error, which is going to be the same thing. Whoops. And we'll also return a timestamp. And you're going to see later why I need this.

Let's just leave it like that. And create this timestamp, like that. And since we're on the server here, maybe we want to do something else. We have access to the database, query something, decide what to do next. In my case, I will get the messages for the user. And I'll use the same getMessages function from the previous component. And just use the user ID. And if the messages for the user is longer than, let's say, five, then we can just return user has reached the maximum number of messages and success false and the timestamp. And if all is well, we can insert into the database, validate the path, and finally, return success true.

And if you have a bigger form with multiple fields here, you can also return the validation here, the validation field errors and display those somehow. But I don't need that. It's just a single field. But I have, oh, yeah, and one more thing. If I have an error in this database thing, it will just be copied error boundary. So that's not something I have to worry about.

Now I have a lot of server side logic here. And it would be really good to get this to the message input and to the user somehow. And we can use a new React 19 hook called useActionState for that. And useActionState takes in a function to call, which will be the action, which will just put the submit message here. And it takes in an initial state. And the initial state will just be success false. There we go. And what it returns to us is a generated component state, which will be equal to first the initial state. And then after that, the last return value of the action, that useActionState is wrapping. And we'll also get a wrapped action that we can call submitMessageAction. And then we can put this on the form. And we can use the state to display the error message here underneath the form. So I'll just add an error message here. Just style it with some red text. And I still have a couple of things here to fix because, as the error describes, useActionState is a hook.

I need client-side JS to use this hook. And I'm just going to tell the bundler to load the JS for this component with useClient. And then I still have a TypeScript error because useActionState actually passes an additional parameter to the function that is wrapping. And it's the previous state. This can be useful for other things. But in this case, I'm not going to use it. So I'll just leave it there. And give it a quick type. There we go.

So everything is OK. Let's see if it will work. Oh, yeah, let's put this back. So I'll just say, hey. And then, hello. And then I hit this maxMessageCount. And the error has returned from useActionState or from the function and useActionState. And then it's in the state now. And we can visualize this. And that's nice. But I'm trying to make this feel interactive. So instead of just using this span here, I'll do an effect instead. And if the state returns with an error, we can do a toast of an error with that error. And let's wrap this up and add the dependency array. And it's depending on the error, but also the timestamp so that this can rerun whenever the timestamp changes. And there we go. And now, we'll get a nice toast like that, which is better, which means that I don't actually need this error message down here anymore. But instead of removing it, I'll just leave it as a no script fallback so that for some reason if there is no JS, we still have a way to know what went wrong.

OK. What's next? Well, when I submit this form and I get an error, my field resets. And the reason it's doing this is because with React 19 and the form element with an action property using uncontrolled inputs, the form automatically resets.

And the reason for this is that it kind of emulates the MK form submission behavior, so it's very useful. But in this case, I don't want to reset because maybe I could have changed it to make it valid, right? I don't always want to reset the form. Yeah. And maybe you're used to making like a controlled form state like with Formic or Reactor form. Here we're just using, you know, plain, plain uncontrolled inputs.

But to fix this problem, we can get back to the message, submit message, and we can return also the content or the data that was submitted. In this case, it's just the content. And then we can use this as the default value of the input because we can do that with uncontrolled inputs. So that will just be the content. So now if use action state or the action here returns with content, it will be the default value. Let's see. So now the form is no longer resetting on there.

What else? Well, I'm using a local database here. And in reality, the round trip from the server and back is probably not going to be this fast. It could be kind of slow here. And now when I'm clicking, I don't get this immediate feedback. And if you're submitting a form, maybe you would be like submitting multiple times by accident. This is something we should handle and let the user know that they are they did click the button and they are waiting for something. So luckily use action state actually returns a third value is pending. And we can use this to place to disable the button like that and maybe say something else like if it's pending sending otherwise they send. And now while I'm waiting for this, I will get this nice pending state here. Let me just get back to the valid version. I'm just going to increase the max message count to eight here. And now we will have this nice loading state, reset form, scroll all as well. So that's nice. But what's cool about this form is that it actually works entirely without JavaScript. So I'll just disable the JavaScript here. We go and try it out. So I'm going to say no JavaScript.

So I'm going to say no JavaScript. As you can see, I'm getting this favicon spinner. I didn't get any pending feedback and I didn't get any scrolling but everything still worked. Let's try it again. So yeah, all the default behavior and let's do it again. And then we hit this max message count and the no script fallback is rendered and we have our default value in the field which is pretty cool.

What we've essentially been doing here is progressively enhancing this form, which means ensuring all the basic functionality works at the lowest level of resources and then adding things on top to enhance the user experience for the users with these additional resources available. So let's say that the user is on a slow device and is waiting for JS to download parts and execute. Well, now this form will actually work before any of that has happened and it will ensure the hydration of the components that we do want is faster because we reduce the amount of JS on the client with server components and weaving the automatic scroller together this way. So depending on the user's situation, they will have a better experience but always have a form that works.

I'm not done here though because I want to spend some time to talk about the reusability of this because the pending pattern is nice and maybe I want that somewhere else in my application. Maybe somewhere that doesn't use use action state. So what we're going to do is we're going to just copy this button, cut this button out and we're going to create a submit button instead and say send here. And I'm going to create this inside my UI component folder here, submit button. And I'll just make a new component here and paste in what I had. And I need to get this as pending from somewhere. So there's another React 19 hook we can use for this and it's the use form status. And this hook returns a bunch of things. It returns the pending, the data submitted, the action and the method used.

And this hook returns a bunch of things. It returns the pending, the data submitted, the action and the method used. But I'm only going to use the pending here. And it's using the parent form as a provider to get these values. So we'll just add that. And since this is a hook, I need to make it a client component again. But that's fine. It's just a small component handling our client side interactivity here.

And if it's pending, I don't want to say sending, I would rather say render a nicely styled div with a spinner. And let's also put the children here. And if it's not pending, just render the children. So I'll just add the props here quickly. There we go. And add that to the component. And you can also, if you want to reuse this in a real project, probably you would want to extend the button props. Or you can add an additional loading here to trigger this nice component in a different way. But for this example, we'll just do it like that.

So let's see if it will work. I'm gonna import it here. And then try it out. So I'm getting this nice spinner now. And that's nice. However, the power of this component is that I can actually put this into any component, even message box. This is a server component. And I can just paste it here. Maybe I want a new feature. Reset. I can make a form with an action. Reset messages. And wrap it around the component.

And just really quickly make an inline server function here. It's gonna be a server function with useServer. It's going to be slow. It's going to delete all the messages from the database. And it's going to revalidate the path with the root path. So let me import this. So remember, I'm on the server here. This is a server component. But even though I am, I can still click this and have this button handle all of my client-side interactivity, which means that it's entirely composable. And this is really the power of server components.

Letting smaller leaf components handle your interactivity for you. I'm gonna quickly jump over to another branch and show you one more hook from React 19. So let me just discard all this code and jump over to an optimistic branch here. And I haven't done that much here. Basically all I've done, well, I've been progressively enhancing this further to make it even more interactive.

And I've made another messages component. This is now a client component because it's using the new React 19 hook, useOptimistic. And this hook takes in a state to show when no action is pending, which is our truth from the server, which is the messages here, and an update function. And this update function defines that on optimistic update, the optimistic message will have an isSending set to true. And it returns to us the optimistic messages and a function to trigger optimistic update. And I can pass this to my message input.

And here I've not done that much. I've just added an additional onSubmit so that if we have this JS available, we will run this. Otherwise, we can run the same action as before. And I'm just doing transition, start adding optimistic message. So let's see how this works. So now I can actually do optimistic updates. And then the sending flag will just be temporarily available on this client state that we're creating optimistically. Sorry. I can do more.

And what's happening here is as the server state returns, the client state is discarded. And whatever is in the server state is then the truth. And I can keep sending more until I eventually hit my max message count here at some point. And whatever is not existent, doesn't exist in the server state, is just automatically rolled back, right?

Because whatever is happening inside this optimistic transition is just temporary and it is thrown away as soon as the transition completes. So the bottom line here is that depending on your app, you can now decide by your requirements and you can still use React to form or formic if that's what you want. But React now provides another option and you can use these more primitive features of a form together with React 19 and React Server components to make very robust forms. While maintaining a good user experience and development experience.

So if you want to look at the code for this, it's on my GitHub and the optimistic update is in a branch. So that's it for my talk. Thank you very much.

So being the first speaker, how do you feel after your talk? It's always good to be first and then you can relax and then watch everyone else and then look at them and be stressed. And feel good that you're not feeling the same anymore. Yeah. Now just chill day for the rest of the day.

So I have a question for myself. I'm wondering if there's any other way or other libraries that you can use to also optimize forms. So of course we have the client-side libraries like React to form and formic. But there's also some other libraries. There's one called conform, which is actually using use action state to give you all these features or benefits while also providing this as you type validation. That's a library that I've been checking out recently. It's really cool. It's actually I think it was originally made for Remix. And I just watched a talk by from React Alicante where he was presenting something called Vest.js. Which was like, wow, this is like solving so many problems with validation and everything So there's a lot of other libraries that are probably going to keep improving now that we have these features in React 19. Yeah. Amazing.

Do any of you want to shout out a question? Go ahead. I mean, you would win a cup if you're... Okay. You. There's a question. Can someone pass the mic? If we have another one? Can you raise your hand again, please? Okay. Sorry. Okay. Is it working? Okay. Yeah. Sorry for sitting in like the least convenient spot. Yeah. So I haven't used server components at all. And like one thing that really, I guess, melts my brain with it is like calling directly to the database in my React code.

Is this a pattern that you use currently in like your production services? And do you feel like there are any kind of downsides of that, as well as like the kind of like notation of use server, use client? Like, do you fear like leaking anything potentially? So if you're worried about leaking things, you would probably the place you would encounter that would be in server functions, if you're... Because this is essentially creating endpoints, and you can access them, you can call them. So you need to be careful with what you send back there. Pretty much that's it.

And there is a blog post about one of the Versel core members. I don't know how to pronounce his name. It's about Sebastian Markpacz. Something like that. I don't know. I'm sorry. But he has a post on security with server functions. Because that's where you would make a mistake, if you were to make a mistake. Yeah. And as for the other question, like how it is calling inside your components directly, in my real project, I have an API, so I'm calling the API there. But I mean, when I'm developing with a database directly, I don't know. I don't think there's much that can beat this DX and the speed at which you can develop things. It depends on what you're making. But yeah. And it does take some time to kind of wrap your head around it. But once you do, it feels very natural. Yeah.

Thank you very much for your answer. May I ask your name? Liam. Thank you, Liam, for your questions. I'm afraid that we are a bit out of time for our Q&A. But she will be available. I'll be here. Yeah. She will be here at her Q&A spot. Come talk to me.

Yeah. Right after this talk. So you can come to her and ask more questions. You can also ask questions still in Discord or Slido, if it works for you.

Yeah. So thank you very much, everybody. Thank you. And thank you, Aurora. Thank you very much.

Thank you. Thank you.