Understanding State Management in Server and Client Components

[00:00 - 00:28] All right, welcome to module six. The module where we finally answer the question which probably got you into this course. How do we share a state between server and client components? By now we've covered state, we've covered client components, server components, we've seen how to mix and match them together. So the final question is how do we share state between them? How do we properly manage state on a complex scenario using next year's 13 or upper?

[00:29 - 00:58] So let's first understand the problem at hand and then let's go into the answers. So consider what happens when a server component calls for a re-render. Unlike client components where state is retained between re-renders, which we've seen already, server components don 't have that luxury. They start with a clean slate every time. So take a look at this very simple server component here that renders a list of items. Every time this component renders, it's going to start from scratch.

[00:59 - 02:12] With a clean slate, there is no added code here or inherent mechanism that helps it remember the state of the list of items. There is nothing here to help us. So how can we make this component or any other server component for that matter understand state? There are two answers to this question. One of them is there is no state. The backend doesn't handle state like we're used to thinking about state on the front end. So you could perfectly say server components don't handle state. However, from a more generic point of view of server development, the backend does handle state in other ways. So you could say that there is state on server components. So now the question is which one's right? Is there or is there not state on server components? And the truth is there is state on server components, which is need to figure out how best to handle it based on our needs, because there is no single way to approach this problem. There is no single way to solve or answer the question. In this module, we're going to look at three different techniques.

[02:13 - 03:10] Propped drilling from server into client components, which is a technique that we've seen already in several videos in the past. I've shown components that share some bits of state or data from the server component into the client component. We'll look into more details about that. Then using cookies as a form of state storage. Again, we've seen some hints of that in some of the components we've reviewed so far are going to more detail and also like we'll review the out provide, which makes heavy use of cookies. And finally, the most common case state hydration. We'll look into what state hydration is and how to implement it for your applications. So the question now is why do we care about this? Why can we just leave all state management on the client like we used to do?

[03:11 - 04:12] A crucial point to remember is that server component advocates for a separation of concerns. By decoupling state from rendering, we're not only boosting performance like we 've seen already, especially when it comes to data fetching and keeping data updated on complex applications, but also gain more control over the user's experience. So hopefully by the end of this module, you'll really understand why we really need to care about how to handle state on these server components. But in the meantime, I want you to reflect on this given the female nature of how server components render themselves, where and how we manage state becomes a critical decision. It will shape the way your entire application is architected and it will also impact directly on the performance and the resulting user experience. So this is not something that should be taken from running and this is not something that should be done lately as well.

[04:13 - 04:17] So in the meantime, keep coding as I will say and I'll see you in the next video.