Server Actions Q&A

[00:00:00]
>> Yes
>> How would you do form validation here?
>> How would you do, you need client-side if you if you're gonna do form validation which requires client-side logic then you? So basically the goal is try to push client far down the tree as far as you can right?

[00:00:17]
So like if you realize like I need form validation here, make sure that you take the only part that needs form validation. Take it out and put it in its own component and make that a client. Don't punish the rest of that component, the rest of that page, and force it to be client because you need just some logic, just for this one part.

[00:00:36]
For the one part that you need, make another component, make that a client So, that's how I think about it. Yeah, yes.
>> If you wanted to redirect on, like, form submit success, would you still use revalidate path and just put in a different URL or, well, a different path perhaps?

[00:00:53]
>> Yeah, so revalidate path won't do any redirecting. It will just clean the cache out for that path. But there is a redirect. Let me see. Not that one, is like from next server I believe, let me see. Name is not there. They do have a redirect method that you can use to redirect anywhere if you wanna go there.

[00:01:21]
>> I want you to do authentication checks, do middlewares.
>> So I do have a thing about middleware. So there is no right answer on how to do authentication checks, you can do them wherever you need things to be protected. So because server action run on a server, you can do authentication checks in here as well if you wanted to.

[00:01:41]
You get access to the cookie, you can use cookies in here. You can say, cookies, or cookie. I don't know why it's trying to pull from from here. But Next.js has a cookie thing. So you can access the cookies here. And you know if you have some authentication there, maybe the authentication is on the headers.

[00:02:02]
You can use that inside of the server action which should give you more information you need to lock down the server action, or whatever you wanna do. And the same is true for any server side logic, which means you could also prevent someone from going to a page if you want it to.

[00:02:18]
On the server side, in this page, you could just check the cookies on this page like now you can go here, so you could totally do that too. It's up to you. middlewares more App-wide authentication, like just protect, don't even show this route at all unless they pass this, which is another way.

[00:02:36]
Then you also have API authentication protection, all the way down to database layers. I don't think there's runway. I think you just need to figure out where all your points of attacks are or all the places you need to protect and then do the right strategy for that.

[00:02:49]
>> Someone was asking about if the actions that TLS is running on the server it means it runs on the server via node while others which are client side runs on the browser.
>> Yes 100%, server means it's running in the node environment on a machine, whether it's yours in development or whatever machine you deployed it to.

[00:03:11]
And use client means it's running in the browser like any other React component you've ever made does.
>> Can the actions.ts process be ahead of time compiled?
>> I don't think It can be ALT because I think it has to be dynamic in nature, I mean I guess I'm not sure exactly what they mean by ALT compile like are they saying the TypeScript are they saying.

[00:03:37]
Yeah, that's a tough question, I mean ahead of time could be anything I mean This definitely can't be static. If that's what they're getting to like this has to be dynamic. It's an action that has to be performed on. But you don't wanna memorize this or cache this by default, although you can, depending on what you use, like fetch or you can opt into next year says new caching mechanism.

[00:04:00]
They have a cache function that you could use to pretty much cache anything but now from my understanding, well, that's the thing. The next thing is you don't really need to or have to, like, put too much concern into how things are being compiled is pretty much handled for you.

[00:04:17]
That's why they have conventions. If you follow their conventions, then you opt into their performance, yes.
>> What about conditional error messages based on the error type?
>> Conditional error messages based off the error type. That's a good question. I know what error boundaries you get access to the error objects in the props.

[00:04:37]
I don't know if you get that in the error file. That's a good thing to look at the docs for, let's see. If you do, yeah, you do. There you go. So yeah, you could do that. You could just grab the error here. You also get a reset here.

[00:04:54]
I knew about the reset without the error. So yeah, you can just grab the error here. Look at the error.type, error.message and this would I guess I'll give you some incentive to create a really good error system in your application that had different error codes. And things that your error messages can use to display different types of errors or UIs and things like that.

[00:05:13]
And because this is a client component, you can do whatever the hell you want. So it works. Yes.
>> He's just kind of blinking every time you submit a new to do due to the revalue revalidate path function, is there a way to avoid this? I suppose, is kind of reloading the page or doing some sort of interpreting of the CSS.

[00:05:38]
>> Yeah, so let me see. Like that. Yeah, so I mean, because that's because it's literally doing a full re-render of that page. The only way to avoid it is kind of what I said earlier. If you need your UI to update off of a server mutations, you're probably just use client instead.

[00:05:54]
So I would just go back to what you were doing before server actions came and handle your mutations client side. And that way, you have more control. I think certain mutations are really, really good. For side effects and things that don't need where the UI is depending on a response.

[00:06:14]
Because then you do have to ask yourself questions like that, well, how do I create a really slick UI that doesn't like Flickr like that or something like that? Yeah, you could probably get around it. You could do some smart caching you could do. Some layout stuff like I'm sure you can figure out a way.

[00:06:27]
But if you just did it on the client, you're probably just better off that way for now. Me personally, I'll probably use server access for like tracking analytics, stuff like that. Web hooks, things like that that happened in the background. But when it comes to UI, I'll probably still do client stuff for now.

[00:06:46]
Cool, any other questions?
>> Is it better to use Next.js routing which is file-based, or use custom React routing? I think you already covered React routing earlier, so.
>> Yeah Yeah, I mean, if you're not gonna use Next.js routing, you should probably not use Next.js. [LAUGH] That's like the whole point of it.

[00:07:13]
So yeah, if you don't want to use it or whatever, I would just use React or go look at another framework like Gatsby or Remix or something like that. Cool, any other questions?
>> I guess kind of going off of that, what if you want to have or you have like large application where maybe one file you want to be more like a SPA, a SPAM, is that something that you can integrate or?

[00:07:41]
>> Yeah, I mean, so if you just want one route to be a SPA, no problem. You would just go in here. Let's say, let's pick a file. No, I don't wanna pick a file because it's just gonna break everything. Let's just make a file. Let's make a new folder and we'll just call this spa.

[00:08:01]
And we'll just say page, do tsx, right? Well, first thing you do, boom, basically a spot right now, right? And then from there, the only now, the only thing you have to think about. So now, you're not doing react server components, but you still got to think about server side rendering.

[00:08:19]
You got to opt, you got to figure out like, well, what if I'm doing like window stuff in here, right? And there's a lot of ways to do that. You basically just make sure. Now that anything that involves a window you know, you just wrap an if statement that a if window was here.

[00:08:34]
That means we're on the server so don't do this right if window is here, we're on the browser then do this. That's another way there's packages for that. And yeah, that's pretty much all you need to do like this basically opps you back into like spa land right.

[00:08:48]
And you don't have to worry about or at least for this page. And I think that's what the Next.js team is trying to, they're trying to make sure that that's your choice. Is that like you start off with everything being server everything you perform it in their preferred way.

[00:09:04]
And then when you wanna just kick back out, like for this page, it's actually a video game that I'm making. So it has to be a single page application. Yeah, cool, just do this and just be cautious of service site rendering. So yeah, at this point, it's the same thing that Next.js used to be.

[00:09:19]
So if you ever use Next.js 12, this is Next.js 12 land right here, where it's like all you're doing is worrying about server-side rendering and there might be even a way to opt out of server-side rendering. I don't know how to do it in the app router land, but I know in the pages router land you could.

[00:09:35]
So you might even say don't even render this thing on the server at all, which I can look up but I don't know how to do that in this version. Cool, any other questions?
>> Since we're handling most of the data on the server side, do we still need state management libraries like Redux?

[00:10:00]
>> That's a great question. You would only need state management libraries like that on client components that needed state management. So, I'll give you an example to do form. I don't have to do this on a server. In fact, I personally probably wouldn't. I would probably do this on a client, so I would do a used state here.

[00:10:18]
And do an on change on the input the traditional form. I would traditionally just do that because I wanna control over the UI. So I would do the same thing there and if there were some other app that needed to know about that state, I would have that state management here and it would know about it.

[00:10:36]
So you still get that. He's still not gonna have, cuz like once you get into the browser, you are on a client site land. There's still hydration happening for the things that need to be hydrated. React is still being loaded. So you like you're still gonna have that client side interaction even though all your pages that you might have rendered are just HTML That just means that those pages don't have any javascripts on them.

[00:10:58]
So basically if you just make sure that all the code, I mean in React Next.js will tell you if you try to do anything with like a hook or a state It'll say you need to do use client so you can't miss it. Like you can't mess it up because it'll just be like you can't you can't run this function you got to put you state at the use client at the top.

[00:11:15]
So once you do that, then it's like anything you've ever done. Nothing's changed, so you won't even have to think about that scenario. Only thing you have to think about is that, I can't do this on a component that doesn't have use client. And even then, it would tell you that you can't do that either, that like, this doesn't work here.

[00:11:34]
So it's it's kind of hard to mess up, and I think that's the the right way for them to do it. Is that you can just do whatever you normally have done by opting into it. So yes, you will probably still need state management the other reason is that like state on the server is global.

[00:11:50]
So every person shares the same state, assuming it's not in some serverless environment, at least in development mode. So yeah, you don't wanna be sharing. Imagine you just saw someone typing in your form. Like, that'd be weird. So yeah, you don't want to share state across multiple instances of a client, across a stateful server, because a server will be stateful.

[00:12:14]
In the execution time, so yeah,
>> If we have a server component inside it client and inside its server how is this loaded?
>> That's a great question. So you are able to load server components and clients and clients and servers. It's basically, it's going to be loaded in the order in which you rendered it, right?

[00:12:37]
Actually, Next.js has a good example of this, so I don't have to write a very long one. Let me find it. Let's see if they have that code example. Yeah, basically, here it is. So, basically there are some caveats with how you can like I said, it comes down to what's being loaded first and like what props you're passing to it.

[00:12:58]
But here's an example of like what's not supported. So like you cannot just by default import a server component into a client component. So like, for instance, here's a client component, you have this server component and you're trying to bring it in. So by default, that won't work.

[00:13:13]
So instead, you have to, in this example, they're wanting you to, like use a prop as a server component. And what you can render it that way, right? So in this case, they you can pass the server component as a child prop of the client component, right? So you're not actually rendering the server component in the JSX of the client component.

[00:13:42]
Instead, your client component is acting more of a layout or a template in which it renders any children that are passed to it. And then through some intermediary server component you can import that client component and have the server component be a child of it. Basically, you just literally cannot import a server component into a client component.

[00:14:06]
Can they be rendered next to each other? Yeah, like this. You just can't import it in. You have to find a way to do it this way. You can only import a server component into another server component. But you can import a client component into a server component.

[00:14:26]
Any questions on that? That's kind of confusing, I had to think about it from I was like. Now, they have a good ride opponent here though that talks about all the things.
>> So do the two server components run first?
>> Do the two server components run first?

[00:14:46]
Well, because they happen on the server, they would get executed. And then the client would probably be server-side rendered. So they will all probably be ran near the same time. The only difference is the client component will then be bootstrapped on the front end, whereas the server components won't.

[00:15:11]
>> So with the form example, we use client. Does the validation wrap this server component to the server component or do the data fetching and stuff?
>> I think the question was, because we have this this to-do form here that's being rendered inside of a server component. How does the server component pass down props to the forum if the forum was a used client, if it was a client component?

[00:15:43]
And what does that look like? As long as it's a serializable prop, it's got to be fine. So you shouldn't have a big deal there. But I think what they're asking is like, well, how does the server component that's rendering this to-do form know when this form was submitted?

[00:15:58]
Because it can't. Like call a function or something like that. Yeah, it wouldn't because you can't pass a function as a prop so either this will have to remain server like it is now. Or you make this a client and then you also make the thing that needs to know when this thing is done a client and then those would be two client components because there's no other way around it.

[00:16:17]
So you just that's when you opt back into like, you guys need to figure out a way to push this down even further or like everything that needs this is just gonna be a client. Like it's not wrong to have a client component like, I don't want people to like avoid them like the plague like that is not the case.

[00:16:33]
Use clients as much as you need, but the way you should be thinking about is like only when you need it. So it should be less of them, not because they're bad but because you don't need them as much as you thought you did.