00:08
if we have instances where after we submit our form, we need the user's scroll position to be maintained, that's perfectly doable here as well. And it's relatively similar to how we
00:17
saw with the link component. So on our form, let's go ahead and give ourselves a padding top of 32, just to give us some scroll position between our heading and our form itself so that we can
00:25
visually see it. So if we jump back to our browser now, we see that there's this huge gap in between register and our actual form, and we have this slight scroll ability going on.
00:33
If we want to maintain our scroll position whenever we actually submit this, so currently if I scroll all the way down here and hit register, or jump back up to the top, just
00:40
as we did with our link component, we can add in a preserve scroll attribute onto our form post method. Remember the second argument here is where all of these options go, so in addition
00:50
to our on success, we can break that down slightly into a new line so it's a little bit more maintainable, and add in a preserve scroll option and set that to true. And now whenever we submit
01:00
and send out this post request, Inertia will preserve our scroll position and leave us where we are without scrolling us back up to the top of the page. So if we jump back to our browser now,
01:09
scroll it all the way down yet again, let's hit register, and you'll see that we maintain our scroll position and we're not jumped back up to the top like we were previously. This is fantastic
01:18
for forms that redirect the user right back to where they were, that way the experience isn't jarring for them. Now there's also going to be times where you're going to need to mutate the
01:25
values before you actually post them out from what the user has submitted. This could be tacking something in addition onto any of the values, doing any client-side validation, setting
01:34
defaults, and the like. So let's go ahead and hide our browser back away and see what that looks like. So again this is off of our form, and we can just chain this in between our form and our post method,
01:42
and make use of the transform method to do this. For this we need to provide a callback function, and the callback function is provided our form data. What we need to do is just return back
01:51
a mutated instance of that data. So we can go ahead and spread that data in, and let's say
01:56
we need to transform the full name. So we can readFromData.fullName, and let's tack on maybe just example to the end of it, just to make some form of a change there. Okay, let's give that
02:06
a save, jump back into our browser, and let's see what it looks like. So let's fill out something here for our full name. So Tom Govich, we'll put in our email, and something there for the password,
02:15
hit register, that's sent out. You see it right down here for our post request. Let's take a look at a request, and you'll see that our full name sent up is Tom Govich example. So example got
02:24
appended on via that transform method. So if you need to mutate your values in any way before actually submitting them out, you can easily make use of the transform method to do exactly that.
02:32
And of course, if at any time your submit handler feels a little too jarring to take a look at, you can extract all of this out into an event handler instead of doing it directly inside of
02:42
the submit.prevent. So we can do onSubmit there for our event, scroll up to our script, find a function for onSubmit, and then plop our form, its transformation, and the post request
02:52
into there. Now whenever we are resetting our form, by default if we don't pass anything into it, it will reset all of our fields. If we just want to reset one or two, we can pass those in
03:02
individually to the form reset, and it will only reset the ones that we specify. So if we just want to reset, say, our full name there, we can pass that in, and you can do a comma, and just
03:10
keep adding them in as applicable to your use case. So if we open up our browser again, let's give it a refresh there to refresh everything, fill our fields out again, and then hit register, you'll
03:18
see that we still have our email and password field, but our full name has been reset now, as that's the only one that we specified to get reset. In addition to that, you can also manually
03:27
specify errors as well. So let's go ahead and add brackets to this so that we can do more than just
03:32
one thing. So we can do form.setError, specify the field that the error is on. So if we wanted to set an error for our full name, we do that there, and then the error value is the second argument.
03:42
This is some error. Jump back into our browser, give that a refresh, fill this out, and let's go
03:48
ahead and register, and you'll see that we get back this is some error displaying on our full name. Now this didn't prevent anything from posting, submitting, or successfully resolving. This was
03:57
merely a client-side error addition to the form itself. So our server wasn't aware of this error that we added in any way. It was added on after the fact manually by us, just in the client. And
04:06
then of course, if you want to clear specific errors, there's a clear error method as well. So form.clearErrors, and just like the reset, you pass in the fields that you want applicable.
04:15
So full name, and any additional that you want to add in there. So there's some of the popular methods that you may or may not want to use with the UseFormHelper.
