The ONE Next.js Feature I Won't Use

so about server actions they make it incredibly easy to handle backend stuff in your front-end code and that sounds weird but they're incredibly convenient you can simply declare a form element in your react component Define a function that should be called when that form is submitted and inside of that form as long as you have the use server directive in there all the code inside of it will run that is guaranteed on the server side that makes server actions Above All Else incredibly convenient and that convenience doesn't just go for the way we declare server actions like you just saw but that also goes for the way we get data inside of them say you had a name input field which value you want to process in the server action simply accept the form data in your function and then get that value from the form data you can't tell me that's not convenient especially when you compare to the boiler plate needed to set up traditional API RS in Ruby in PHP in Express even within next JS itself there's a lot more boiler plate involved in setting up an API route and as convenient as that might seem there's a couple reasons why I'm very skeptical about server actions for example ask yourself why are you learning web development if your main goal is getting a job and I know for some of you that's the main thing you're looking for in this whole web development thing then I would argue there's much better stuff to learn than server actions more on that in a second on the other hand there's loading States and aror states that make up a really good user experience take a look and see if you can tell what happens on the server and what happens on the client because the line in between those two is Extreme ex blurry and at least to me super confusing so for example here is how to do loading States according to the official documentation to me this seems pretty backward instead of being able to determine the loading state in the component where we are using the server action instead of a server component we are expected to move it to a client component for example this button right here this needs to be a client component so that we can make use of a react hook and that is use form status from react Dom and that will actually then contain or pending or loading state from this hook because that is rendered inside of this form and we can also give this button a little conditional opacity of 50 half of what it usually is just so we can see the loading State now all that's left to do is to import this custom client side component into our server side component so we do need two separate components server side and then the client side button that we are importing into the server side component right here and only then are we going to be able to see the loading State oh by the way let's also add a little um await new promise that we delay by like 1 second so we can actually see the API working now if we switch back and click the submit button then you'll see yeah it's now loading for 1 second and we can see the opacity change for the duration of that loading state but just the code in which we achiev this I don't know and honestly the arrow states are not much less confusing for example let's declare this as a client s side component instead from the server site as before and actually in the for we now need something called a client action so that's not inherently or server action rather it's kind of a wrapper around or server action This Server action we now import from a separate file so we don't really have the convenience anymore of declaring it right here in line right above where we need it now this do server side stuff is nothing else than our server action as we had before with the only difference is that we wait one second and actually throw an arrow afterwards so we can then see how to handle it and this way of returning an actual series iable error object is pretty neat I mean I do have to give that to the server actions I really enjoy that approach because that allows us to then check wherever we call this server action in the result well do we have an error or not and if we do then for example we can simply alert the error that we get for example the string of you know this didn't work try again and this works if we take a look at it we get the loading State because the my button that we have right here stays exactly the same as we had before but I really dislike this approach and one main reason is where is the client where is the server it's pretty hard to tell this is apparently a client side component but this runs on the server but this runs on the client and then we have use server in the actual action file and the use client in all the other files like the button so we can have a react hook inside of it if you compare that approach we just saw from server actions to something like trpc and yes technically both of these server actions and trpc are trpcs they're typ safe remote procedure calls because they abstract away the logic and let you call from the front end a method on the back end in a types safe way but if you take a look at the difference in trpc we can simply destructure the loading and the arror state we could also attach an onerror callback if anything goes wrong in server actions as you just saw that is a bit more involved and it happens through the client and the server and where is the line and as I teased earlier there's the whole why are you learning this thing if your goal is a job then understand that 99 99% of companies even nextjs as a whole is a super new involvement and in any job very very likely you will not be using server actions you will need to know proper API design patterns and I would argue if you start your journey with server actions and never actually Implement proper API patterns like rpcs yourself then there's likely going to be a lot of learning you'll have to do when you get that first developer job it was the same way for me I thought I was pretty all right at the whole back and stuff and then when I got my first full-time developer job and saw this gigantic code base that uses exclusively rpcs remote procedure calls wow how does this work and I needed like a month of understanding how to do this how to implement this myself until I finally got the hang of it and I just wish I had done it earlier learn proper API design patterns and with server actions I think you're quite missing out on that part plus they're kind of out of question if you have like an IOS app and an Android app and a web app they all need to communicate with the same backend and because of the nature of server actions being not publicly accessible you can't really realize that infrastructure with server actions in the first place so the only use case I see for them is to create fast small MVPs minimum viable products a prototype of your app really quickly that's what I think they're really good for besides that I can't really think of a use case where server actions would be more beneficial than a traditional API approach or something like trpc that gives you type safety along the way what's your opinion on server actions I would really like to hear your thoughts I know some of you really like them and that's totally cool let me know down in the comments below what you think about them and I'm going to see you in the next video have a good one and bye-bye

Channel: Josh tried coding

Views: 16,920

Keywords: react, nextjs, server actions, nextjs 13, nextjs 14, server actions nextjs, react server actions, rsc, typescript, josh tried coding, joshtriedcoding

Id: rwvz6boeBrw

Length: 6min 38sec (398 seconds)

Published: Sun Nov 26 2023