My comment is not related to anything I just want to say you have a friendly face and great personality, man. If you're a manager/ leader I'm 100% certain you're great at it
This is a good explanation. We should be relishing RSC Architecture for several reasons, my favourites being server rendering and security. There's a bit of a learning curve when it comes to distinguishing the difference and making a decision between client and server components. We are heading in a direction where server components will become the default unless your page requires a lot interactivity.
You're one of the few creators that show real life scenarios and real life solid solutions, not like most tutorials based on a script lol. I wanted to ask if you have a preferred way to handle errors, or the best practices, in javascript, especially when using the try catch syntax Should I be creating new custom Error classes and then handling them independently in the catch block with if(error instanceof CustomError) or is it better to always return an object followind a contract with either a data property for success >>> "{data: [....]}" or error property for error >>> "{error: ....}" Or maybe you know a better and more solid way, would be really helpful, thank you
Great question! I don't think there's a one size fits all answer here. Both approaches (using the catch block and returning an object) can be useful at different times. I'd throw and error and use a catch block for the times when the error is an exception. Things where there's no obvious next step, like a database connection failing. Not much you can do in this situation, so throw an error and catch it somewhere else. And I'd return an error object for that times when there is a next step. If a login() function fails then I know what the next step is, it's to display an error message telling the user their credentials are wrong. That's not really an exceptional situation, so I'd return an error and let the code decide what to do next.
You can use my RSC philosophy whenever you have mutable data to handle you should have client components otherwise for immutable data you should use server components
I have a list of static blog posts that have a like button. That like button is displayed differently for users who did like a post. Does it make sense to have that like component a client component while fetching the data using a server action?
Hey there! Great question :) It's always tricky when you have a static page that needs to have 1 or 2 small dynamic elements. I think there's two ways to go about solving this: 1) Your page isn't really static anymore since it has dynamic elements. Have the RSC fetch data to determine which version of the like button the user should see. 2) The other option would be to keep your page static and do client side data fetching. That sounds like what you're suggestion with the server action. The only thing to be aware of is that server actions are made for mutations, not fetching data, so it's better to use an API route to fetch the data needed to display the button. Personally I'd go with option 1, but I think option 2 is okay if keeping the page static is a hard requirement for you. Hopefully that helps but please let me know if anything isn't clear!
if we include the markdown component in the client, the marked library will get bundle to the client right? wont think rsc will save anything here right?
Yup, exactly! Once you include Markdown in a client component everything is shipped to the client. RSC saves the index page from having to download the marked library. Only users who visit the edit page end up downloading marked.
![DDG & G Herbo - Nosey [Official Video]](http://i.ytimg.com/vi/I9Ra0Zc2NlQ/mqdefault.jpg)
My comment is not related to anything I just want to say you have a friendly face and great personality, man. If you're a manager/ leader I'm 100% certain you're great at it
This is a good explanation.
We should be relishing RSC Architecture for several reasons, my favourites being server rendering and security. There's a bit of a learning curve when it comes to distinguishing the difference and making a decision between client and server components. We are heading in a direction where server components will become the default unless your page requires a lot interactivity.
Rendering and security are great points! Thank you
You're one of the few creators that show real life scenarios and real life solid solutions, not like most tutorials based on a script lol.
I wanted to ask if you have a preferred way to handle errors, or the best practices, in javascript, especially when using the try catch syntax
Should I be creating new custom Error classes and then handling them independently in the catch block with if(error instanceof CustomError) or is it better to always return an object followind a contract with either a data property for success >>> "{data: [....]}" or error property for error >>> "{error: ....}"
Or maybe you know a better and more solid way, would be really helpful, thank you
Great question! I don't think there's a one size fits all answer here. Both approaches (using the catch block and returning an object) can be useful at different times.
I'd throw and error and use a catch block for the times when the error is an exception. Things where there's no obvious next step, like a database connection failing. Not much you can do in this situation, so throw an error and catch it somewhere else.
And I'd return an error object for that times when there is a next step. If a login() function fails then I know what the next step is, it's to display an error message telling the user their credentials are wrong. That's not really an exceptional situation, so I'd return an error and let the code decide what to do next.
@@RyanToronto Thank you! That makes a lot of sense :D
You can use my RSC philosophy whenever you have mutable data to handle you should have client components otherwise for immutable data you should use server components
interesting way to summarize it! thanks!
I have a list of static blog posts that have a like button. That like button is displayed differently for users who did like a post. Does it make sense to have that like component a client component while fetching the data using a server action?
Hey there! Great question :) It's always tricky when you have a static page that needs to have 1 or 2 small dynamic elements. I think there's two ways to go about solving this:
1) Your page isn't really static anymore since it has dynamic elements. Have the RSC fetch data to determine which version of the like button the user should see.
2) The other option would be to keep your page static and do client side data fetching. That sounds like what you're suggestion with the server action. The only thing to be aware of is that server actions are made for mutations, not fetching data, so it's better to use an API route to fetch the data needed to display the button.
Personally I'd go with option 1, but I think option 2 is okay if keeping the page static is a hard requirement for you.
Hopefully that helps but please let me know if anything isn't clear!
@@RyanToronto Thanks a lot for the insight!
if we include the markdown component in the client, the marked library will get bundle to the client right? wont think rsc will save anything here right?
Yup, exactly! Once you include Markdown in a client component everything is shipped to the client.
RSC saves the index page from having to download the marked library. Only users who visit the edit page end up downloading marked.
👌💯