My opinion is that when a concept is very difficult to explain it is because something doesn't sound right. But your explain this two concept very very well.
wow this is superb and icing on the cake after researching this topic for days, finally I can sleep well. My question is Server Components are like Virtual DOM in the server? Like they are literally components in the React server who have its own virtual DOM?
The whole point of the virtual dom is to track changes in the state, and there isn’t really any server-side state (useState only works client side). But RSCs are still components structured in to a component tree. It’s just the the idea of the Virtual DOM doesn’t really apply to the server side :)
@@KodapsAcademy yeah the tree that's what I meant, like tracking the nodes (in this case, components in server) and changing only the specific node without having to re-do the entire tree
Great explanation. I've just one question: what happens when a components that should not be client (server) for example that have only jsx with no interactivity or smth is marked with a use client label at the top of the file, will this lead that the mentioned component in a (pseudo logic) will be mounted to the html via JavaScript bundle or in all cases it will be pre rendered/generated on the server Also does the terminology "pre-render" always exits with RSC, because I'm confusing between the idea of mounting the html code from js and the prerender thing (take the initial values of the useState to generate initial html)
Client components are indeed pre rendered on the server (as HTML, initially, and as the streamed JSON payload thing in updates), the "use client" directive is used to declare where interactivity will be managed. i.e. if there is an onClick or a useState in the component, it must be on the client. In the case you are describing, the server does the initial render, and then nothing happens particularly since there is no client specific behavior in the component you are describing
You have got a good video with great content here, however, I feel that your voice audio is way too low and it’s making it very difficult for me to concentrate on what you are saying please consider increasing the volume of your voice relative to everything else. Thank you.
I have read somewhere that any components that has user interaction like click or anything shiuld not be a server component. However, in your exMple you have todo component as server component which i am speculating would have user events involved. Please correct me if my understanding is wrong?
The idea that user interactions can only be client side is a bit of an oversimplification. The best counter-example is a user registration form. It can have client-side logic for providing feedback e.g. on password strength, but the core of the behaviour is still server-side. For the todo list you might want to have some client-side interaction e.g. for rearranging the list, but if we want to store the list in a database, it makes more sense to have a server component. If you want a component with *only* client-side interaction which is not stored in a DB (.e.g opening a dropdown), then it makes sense to have it as a client-side component.
@@KodapsAcademy Thank you for the explanation. What i am actually getting at is if a Tolist contains update or delete for every items in the list. Will it be possible with a Server side component?
Is it possible to fetch data on a client side component and feed it down to a server side component? Now that I think about it, I have no idea why the app I’m building is structured like that but it might just be down to not having enough understanding of the concepts
Im pretty sure you can just do a fetch request in your client component then pass it down to the server component through props. Do note though that server components nested inside of client components automatically become client components.
Server component can be run on the client *if* there is no server-side logic to them, e.g. no data fetching going on inside them. It is kind of a waste though, if you're in a situation where you can have server components your code will be cleaner and clearer if you fetch the data from them (you can trust server components a lot more so auth is easier, you're closer to the data, and above all the data fetching becomes the responsibility of the component actually using the data). Without actually looking at your code and your tech stack it's difficult to give good advice, but at first glance it sounds like there might be a better way to go about it :)
Server component if it’s nested inside client component (and not passed as prop) it become client component, “use client” directive is boundary to separate client side from server side.
Without an explanation of how the RSC work it all looks like a magic and nothing is clear. So rendering a RSC produces some kind of a data structure, what's next? How this data structure is used to update the client components in the browser?
This is only video that helped me to understand server components easily. Thanks man
Thanks for the simple and precise explanation. Background music and animated content are definitely engaging.
My opinion is that when a concept is very difficult to explain it is because something doesn't sound right. But your explain this two concept very very well.
Thanks :)
Awesome explanation!! BTW, I loved your style, the light of the video and the way you speak; it's like you were delivering a poem.
first time watching ur videos and I have to say that besides the learning the concept, I like how you explained it! subbed for sure.
Could you please explain why SEO is not affected by streaming in that weird JSON-like syntax?
Agreed, I don't see how it could be SEO friendly unless the initial server render contains the entire HTML tree.
Hello
Any news on that topic?
The json syntax is for server side updates, the initial render is HTML :)
wow this is superb and icing on the cake after researching this topic for days, finally I can sleep well. My question is Server Components are like Virtual DOM in the server? Like they are literally components in the React server who have its own virtual DOM?
The whole point of the virtual dom is to track changes in the state, and there isn’t really any server-side state (useState only works client side). But RSCs are still components structured in to a component tree. It’s just the the idea of the Virtual DOM doesn’t really apply to the server side :)
@@KodapsAcademy yeah the tree that's what I meant, like tracking the nodes (in this case, components in server) and changing only the specific node without having to re-do the entire tree
Damn this was a good watch. Thank you sir for spreading your knowledge : )
Glad you liked it and glad I was able to be helpful :)
Great explanation.
I've just one question: what happens when a components that should not be client (server) for example that have only jsx with no interactivity or smth is marked with a use client label at the top of the file, will this lead that the mentioned component in a (pseudo logic) will be mounted to the html via JavaScript bundle or in all cases it will be pre rendered/generated on the server
Also does the terminology "pre-render" always exits with RSC, because I'm confusing between the idea of mounting the html code from js and the prerender thing (take the initial values of the useState to generate initial html)
Client components are indeed pre rendered on the server (as HTML, initially, and as the streamed JSON payload thing in updates), the "use client" directive is used to declare where interactivity will be managed. i.e. if there is an onClick or a useState in the component, it must be on the client. In the case you are describing, the server does the initial render, and then nothing happens particularly since there is no client specific behavior in the component you are describing
Good work, you did say that SOMEWHERE javascript deserializes the streamable text, is that SOMEWHERE what we call the EDGE environment?
Thanks a ton , this for me cleared a lot of confusion.
You have got a good video with great content here, however, I feel that your voice audio is way too low and it’s making it very difficult for me to concentrate on what you are saying please consider increasing the volume of your voice relative to everything else. Thank you.
Voice volume is fine and clear.
Wow, great video and production. Subscribed!
Super didactic explanation, thank you for this.
Glad to be of service :)
Wow documentry style programing videos. definetly subbing.
I have read somewhere that any components that has user interaction like click or anything shiuld not be a server component. However, in your exMple you have todo component as server component which i am speculating would have user events involved. Please correct me if my understanding is wrong?
The idea that user interactions can only be client side is a bit of an oversimplification. The best counter-example is a user registration form. It can have client-side logic for providing feedback e.g. on password strength, but the core of the behaviour is still server-side. For the todo list you might want to have some client-side interaction e.g. for rearranging the list, but if we want to store the list in a database, it makes more sense to have a server component. If you want a component with *only* client-side interaction which is not stored in a DB (.e.g opening a dropdown), then it makes sense to have it as a client-side component.
@@KodapsAcademy Thank you for the explanation. What i am actually getting at is if a Tolist contains update or delete for every items in the list. Will it be possible with a Server side component?
I love the way you explain things, really reminds me of Marco Pierre White. Subscribed!
Is it possible to fetch data on a client side component and feed it down to a server side component? Now that I think about it, I have no idea why the app I’m building is structured like that but it might just be down to not having enough understanding of the concepts
Im pretty sure you can just do a fetch request in your client component then pass it down to the server component through props. Do note though that server components nested inside of client components automatically become client components.
Server component can be run on the client *if* there is no server-side logic to them, e.g. no data fetching going on inside them. It is kind of a waste though, if you're in a situation where you can have server components your code will be cleaner and clearer if you fetch the data from them (you can trust server components a lot more so auth is easier, you're closer to the data, and above all the data fetching becomes the responsibility of the component actually using the data). Without actually looking at your code and your tech stack it's difficult to give good advice, but at first glance it sounds like there might be a better way to go about it :)
Server component if it’s nested inside client component (and not passed as prop) it become client component, “use client” directive is boundary to separate client side from server side.
Without an explanation of how the RSC work it all looks like a magic and nothing is clear. So rendering a RSC produces some kind of a data structure, what's next? How this data structure is used to update the client components in the browser?
Excellent work, sir
Thank you for your kind words !
Thank you for this clarification
This video is brilliant.
Nice explanation sir.
thank you
Glad to be of service :)
Thank you.
Glad to be of service :)
wow cool, thanks
subscription