Amazing video, Lazar. One thing I noticed is, you are very comfortable working with NeoVim, but as someone like me who have never tried it, it is kinda confusing. Do you have a plan to record your videos using Vscode?
Thank you! I would be a lot more descriptive to what I'm doing in a video than a live stream. If I'm going to a certain file I'd say it out loud, so even viewers who aren't using Neovim can understand what's going on and are able to follow along. Live streams are where I figure stuff out 😅 Appreciate the feedback though.
I know this video wasn't about form validation. But I couldnt see rhe part where live client side validations were used from the zodschema with react hook form. Is there another video where you show us how client side validation with live errors are shown to the user?
You can see the definition above the "useServerAction" usage, but I actually created a gist for you: gist.github.com/nikolovlazar/824dd3efb67228f673e40494ed8e63a4. Hope this helps!
@@nikolovlazar this looks good. Very readable. Just a little confusion though. Where will the errors show up in the jsx? Is it the j component? Also shouldn't there be a onChange mode enabled on react hook form?
@@AmitErandole Yes it's the component. These components are from the shadcn/ui library. Here's how it's implemented if you want to replicate it, but don't want to use shadcn/ui: gist.github.com/nikolovlazar/a270127f8a3271a1d6db289030048b57. It's basically using the "useFormContext" hook that comes from "react-hook-form" to obtain the parent field state, in which the error is defined.
Hey Lazar, thanks a lot! Would you recommend using clean architecture infrastructure over the Server actions/ZSA approach? Or would using both be overkill? ZSA procedures already doing the controller job right? (Not to mention the fact that the framework is not decoupled from the interface layer) I need to expose my HTTP API, so I dlike to share the controllers functions/ZSA actions with both the HTTP API route handler and client components. Is it considered good practice to call ZSA actions from the API route handler? I also looked into IRPC, but I'm a bit lost. Is IRPC obsolete with server actions + ZSA/next-safe-action? Thank you so much for your help!
Glad you liked it! Treat the controllers as part of your core app’s logic, and everything framework-related as a “consumer”. You want all crucial logic like input validation and auth checks to be in your core app logic, so all consumers will function the same. Instead of calling a server function inside of an api handler, just call the controller in both places and handle the errors accordingly. That would be the smartest way to go about this.
Hi all I try zsa but request is still show in network and I can see the payload. It's the same in the zsa documentation. I though request are made on the server side. I'm using react not nextjs
server actions are executed on the server, but the client has to perform an HTTP call to invoke them. That's why you see it in the Network tab. that doesn't mean that the action was executed in the browser.
It's very good I think, but why not separate the supabase logic in usecases for example, so that if you have to change bd or provider you won't need to touch your server actions which are already well structured
Thanks for the content! Can I clarify if it's possible to make a solid background without the light spot in the future? For some reason it's hard to read because of it
@@nikolovlazar thank you, I know those videos are long because are made in a Livestream mode, not like a course or tutorial, but I wonder if the app is completed after the last video? And if db room, mvvc, di, and other stuff like that is covered?
This is my Neovim IDE! You like it? I can create a video on how I set the whole thing up, but my configuration is always changing so the video will get outdated pretty quickly. I do keep my config open source though: github.com/nikolovlazar/dotfiles Feel free to poke around and see how I configured neovim.
Simply don't write serious backend code with server actions. Anything beyond basic usage will end up in a messy unmaintainable code. Next.js isn't suitable for a scalable backend application. Imagine doing RBAC, rate limiting, metering, heavy middleware actions, and load balancing with server actions or the route.js/ts setup.
I believe Vercel only recommend SA with specific use cases, i.e. mutations, like basic CRUD operations. But definitely is not a replace for an entire backend IMHO.
I believe Next.js isn't a one-size-fits-all solution, just like any other framework, but I'm curious to hear about where you hit the limits of it. In what use cases have you reached the limits of actions, but you couldn't get the job done? Not being sarcastic, I genuinely want to know 😁 this could be a really good discussion, and even a video topic!
@@nikolovlazar Exactly the same thing I was thinking about. When implementing something like that, even the clean architecture in Next.js feels wrong somehow, but it's working, and we have 0 problems. Maybe this is the future of web development: monolithic frameworks.
@@nikolovlazar Unrelated to the original comment about code scalability, but one problem Next.js has is that WebSockets & SSE don't work with it since you will deploy it to a serverless environment (unless you use a 3rd party solution like pusher for eg). As for the original comment, I think that if you organize your code well with good separation of concerns, it can allow you to go very far
@@TianYuanEX Yep, sockets are definitely out of question in a serverless environment. But there's definitely a way to keep a good code structure and not have (major) issues!
You'll find yourself repeating a lot of code when you need to share common pre-exec logic between multiple actions. Think about authentication, input validation, analytics, instrumentation, etc... That's when using ZSA (and next-safe-action as well) shines. If you don't do those things, then using these libraries will most likely be an overkill.
Zsa let’s go!
Amazing Videos for me to learn. I hope you make many more
Glad you enjoy them!
Cool! Thank you for sharing such nice approach!
Amazing video, Lazar. One thing I noticed is, you are very comfortable working with NeoVim, but as someone like me who have never tried it, it is kinda confusing. Do you have a plan to record your videos using Vscode?
Thank you! I would be a lot more descriptive to what I'm doing in a video than a live stream. If I'm going to a certain file I'd say it out loud, so even viewers who aren't using Neovim can understand what's going on and are able to follow along. Live streams are where I figure stuff out 😅 Appreciate the feedback though.
amazing, appreciate your work.
ZSA IS HERE 👍😅😊
I know this video wasn't about form validation. But I couldnt see rhe part where live client side validations were used from the zodschema with react hook form.
Is there another video where you show us how client side validation with live errors are shown to the user?
You can see the definition above the "useServerAction" usage, but I actually created a gist for you: gist.github.com/nikolovlazar/824dd3efb67228f673e40494ed8e63a4. Hope this helps!
@@nikolovlazar this looks good. Very readable. Just a little confusion though. Where will the errors show up in the jsx? Is it the j component? Also shouldn't there be a onChange mode enabled on react hook form?
@@AmitErandole Yes it's the component. These components are from the shadcn/ui library. Here's how it's implemented if you want to replicate it, but don't want to use shadcn/ui: gist.github.com/nikolovlazar/a270127f8a3271a1d6db289030048b57. It's basically using the "useFormContext" hook that comes from "react-hook-form" to obtain the parent field state, in which the error is defined.
@@nikolovlazar great. Thank you so much for sharing this. Helps me connect the dots
@@AmitErandole Of course! I'm glad I can help!
Hey Lazar, thanks a lot! Would you recommend using clean architecture infrastructure over the Server actions/ZSA approach? Or would using both be overkill? ZSA procedures already doing the controller job right? (Not to mention the fact that the framework is not decoupled from the interface layer)
I need to expose my HTTP API, so I dlike to share the controllers functions/ZSA actions with both the HTTP API route handler and client components. Is it considered good practice to call ZSA actions from the API route handler? I also looked into IRPC, but I'm a bit lost. Is IRPC obsolete with server actions + ZSA/next-safe-action?
Thank you so much for your help!
Glad you liked it! Treat the controllers as part of your core app’s logic, and everything framework-related as a “consumer”. You want all crucial logic like input validation and auth checks to be in your core app logic, so all consumers will function the same. Instead of calling a server function inside of an api handler, just call the controller in both places and handle the errors accordingly. That would be the smartest way to go about this.
great job Lazar
Thank you!
What’s the advantage of zsa over something like next-safe-action?
I haven't used next-safe-action, but just by glancing at the docs it looks like it does the same job for the most part.
@@nikolovlazar 🙏 Thanks. Love this series btw.
@@semyaza555 Thank you!
Hi all I try zsa but request is still show in network and I can see the payload. It's the same in the zsa documentation. I though request are made on the server side. I'm using react not nextjs
server actions are executed on the server, but the client has to perform an HTTP call to invoke them. That's why you see it in the Network tab. that doesn't mean that the action was executed in the browser.
So basically zsa is trpc but for server actions 😅
Pretty much! 😂
It's very good I think, but why not separate the supabase logic in usecases for example, so that if you have to change bd or provider you won't need to touch your server actions which are already well structured
That’s what we’re doing! We’re still not done with the refactoring, but my goal is to isolate supabase and other elements of the stack into layers.
Thanks for the content! Can I clarify if it's possible to make a solid background without the light spot in the future? For some reason it's hard to read because of it
Absolutely! Thank you for the feedback 🙏
Thank you
Hey! Your videos really interested me on clean architecture. Do you recommend any books on that topic?
That's great! I personally haven't read anything other than "Clean Code" and the "Gang of Four (GoF) Design Patterns". You can also ChatGPT it 😁
What are your thoughts on next safe actions?
Haven't used it, but it's probably a decent library like ZSA.
Hi buddy, could you provide your nvim config? It's pretty cool
Sure thing! github.com/nikolovlazar/dotfiles
🔥🔥🔥
❤
🤯 😍
Cool to know but man too much work, also I love how server actions turning into trpc slowly 😂
It’s worth it! 😁
no way, brother where are the videos of the expense tracker app
Had to move them to a different channel: www.youtube.com/@lazars-streaming-archive. The React Native are coming tomorrow and Monday.
@@nikolovlazar thank you, I know those videos are long because are made in a Livestream mode, not like a course or tutorial, but I wonder if the app is completed after the last video? And if db room, mvvc, di, and other stuff like that is covered?
The app is completed, but no DI or architecture or anything like that. There is a database though, so it is in a usable state.
Have you tried next safe action btw? What is the difference?
Haven't yet. I think for the most part the libraries are pretty much the same, but I haven't taken a better look at Next Safe Actions.
What is that IDE?
This is my Neovim IDE! You like it? I can create a video on how I set the whole thing up, but my configuration is always changing so the video will get outdated pretty quickly. I do keep my config open source though:
github.com/nikolovlazar/dotfiles
Feel free to poke around and see how I configured neovim.
@@nikolovlazarpls make a video to setup exactly similar to yours
@@crossmindedninja5522 let's do it!
Simply don't write serious backend code with server actions. Anything beyond basic usage will end up in a messy unmaintainable code.
Next.js isn't suitable for a scalable backend application. Imagine doing RBAC, rate limiting, metering, heavy middleware actions, and load balancing with server actions or the route.js/ts setup.
I believe Vercel only recommend SA with specific use cases, i.e. mutations, like basic CRUD operations.
But definitely is not a replace for an entire backend IMHO.
I believe Next.js isn't a one-size-fits-all solution, just like any other framework, but I'm curious to hear about where you hit the limits of it. In what use cases have you reached the limits of actions, but you couldn't get the job done? Not being sarcastic, I genuinely want to know 😁 this could be a really good discussion, and even a video topic!
@@nikolovlazar Exactly the same thing I was thinking about. When implementing something like that, even the clean architecture in Next.js feels wrong somehow, but it's working, and we have 0 problems. Maybe this is the future of web development: monolithic frameworks.
@@nikolovlazar Unrelated to the original comment about code scalability, but one problem Next.js has is that WebSockets & SSE don't work with it since you will deploy it to a serverless environment (unless you use a 3rd party solution like pusher for eg).
As for the original comment, I think that if you organize your code well with good separation of concerns, it can allow you to go very far
@@TianYuanEX Yep, sockets are definitely out of question in a serverless environment. But there's definitely a way to keep a good code structure and not have (major) issues!
I don't understand why you would do all of this. The NextJS documentation already shows best practices for using server actions
You'll find yourself repeating a lot of code when you need to share common pre-exec logic between multiple actions. Think about authentication, input validation, analytics, instrumentation, etc... That's when using ZSA (and next-safe-action as well) shines. If you don't do those things, then using these libraries will most likely be an overkill.