>> Scott Moss: Let's do it.
Go to our Mode here.
Okay, that clearly wasn't the place to put that form cuz it looks bad [LAUGH].
So we can figure out where to put it later, it's not a problem.
Let's just test the functionality.
So if I say, I think I already use this one,
user@user.com password.
Let's just see if the validation works.
So I think the password says,
there has to be a minimum on the password, I think.
Password, where is that?
Thought I had a minimum on the password.
I think it's server side maybe, let's see.
Yep, I do.
So password minimum has to be at least 6.
So we can test that.
So if I say like admin, admin, I click Sign up.
Boom, validation failed, password must be at least 6.
So I know that that actually hit the server cuz that's a server validation,
that happens on the server side.
Just to show you that it happens on the server side.
You can see that there was a route here for post sign up.
Wait, I didn't do that, did you do that?
I didn't do that, I didn't make a route for that.
That's the server, that's the action, right?
So now let me go to signUp inside of here.
Let's put a log in here.
Do you think I'm gonna see this in the console in the browser or
in the logs on the terminal?
>> Speaker 2: Terminal.
>> Scott Moss: Right.
Cool, here from the server, it's running on the server.
user@user.com, admin, admin.
Boom, okay, right here.
It made a request, made a post request 2/signup.
Here's the Payload, it's a form data.
It submitted a form.
It has to cross the network.
This is no way for it to not do that, that makes sense?
In the case of a form action, it's always just submitting to the route that you're
on cuz that's just how forms submit.
Forms submit to the route that they're on unless you give a different action.
If you use a server action not as a form action, then it has to make a route.
Yes.
>> Speaker 3: Are server actions in NextJS the same as actions and loaders in Remix?
>> Scott Moss: I have no idea, I've never used Remix a day in my life, so
I couldn't tell you, maybe.
Not even gonna lie, never used it, looks cool though.
Let me see if I can figure out actually where this goes.
So it's not ugly cuz it's bothering me.
I think it goes into here maybe.
Yeah, so much better.
I was off just by a little bit.
>> Speaker 3: Do you have any recommendations for
type safety with server actions?
>> Scott Moss: It should be the same as type checking any function you've
ever made because they're just functions.
So there shouldn't be anything new you have to do.
I'm just a typescript hater.
>> Speaker 3: Well, it looks like too you're importing the type from your
auth.ts, so it's the same type in both places.
>> Scott Moss: Right.
>> Speaker 3: It lives in one spot, which is nice.
>> Scott Moss: Right, so yeah, this thing.
I don't know why this thing is freaking out.
Well, other than that, as soon as I see this, I don't care.
[LAUGH] Before we move on to actually fetching the data,
I forgot we didn't actually hook up our sign in page.
But it's essentially the same thing as a sign up.
So let's just get that filled out right quick.
Code's already in here.
Yeah, it's pretty much the same thing.
So get our use client, get our imports, it's gonna bring those in here.
It's really nothing new to learn here other than what we just did for
the sign up.
So not missing out on anything, I just want your app to work.
So I'm just gonna copy that stuff and
I'm gonna hope I put the form in the right place.
Again, which I think is,
let's see, where would that go?
There it goes here.
Let's find out.
Use client rest and replace index.
I put it in the wrong place, my bad.
There we go and then I need to camel case my sign in method.
There we go, you might have to do that if you were following my pushes.
These are either change them camel case here or
change the imports to not be camel case.
Whichever one you wanna do.
And there we go, there's Sign in.
Okay, so Sign up, Sign in.
Looking good.