Utilizing Client Components in React and Next.js

[00:00 - 01:46] Hello and welcome to Module 3. In this module we're going to be looking into client components, what they are, how they're being used, how best to use them and when you should use them. But right now let's focus on exactly what a client component is in the next year's 13 plus context and really see that there is not a lot of differences with what you probably already know and understand of a component if you're coming from React already. So what are really client components? So a client component is essentially a component that needs to be instantiated in the browser because they rely on code that needs either the DOM API, the browser API or at least one of React hooks or any other functions that are specific to the client. So if you use the use take hook, the use effect hook which are very common then automatically your component needs to be turned into a client component. These components cannot and will never be able to run on the server because of these specifically because there is no browser on the server context so their code will really not work in there. So the reason why you want to create client components in your application is because you want to harness the power that the browser gives you through either DOM API directly accessing DOM elements or through maybe the browser API which allows you to access the device like here location API or audio API. Any of those device specific APIs are only accessible to client components and really if you want to show a very snappy and a very fluid user experience that reacts to the user actions then client components are the place to encaps ulate that logic.

[01:47 - 03:01] And how do you define a client component? Well it's actually very simple. If you're coming from React or if you're coming from previous versions of Next then a client component is essentially what you already know as a component. The only difference is that now we use the use client directive at the top of the component essentially the first line of the file has to have that directive. You can see in this example a component that is part of the sample application so you should see it in the code that you have access to and is essentially a small batch that toggles between either the pending message or the DOM message and it reacts to state updates from the global state essentially. Remember that our sample application is a task manager so in the list of tasks each task will have a status either pending or done. The list of tasks is kept on a clearly on a global state because many components of the application need to know about it and this component here is reacting to updates on that list. Essentially whenever we update a task the list is updated and whenever the list is updated this component is also re-rendered because of that.

[03:02 - 03:45] Let me just quickly show you from the interaction point of view how that looks. Here we have the application already showing me three different tasks for my user and if I were to click on any of these buttons each of these individual tasks will be updated to a DOM status on the global task context and because of that this message here this batch which is the indicator that we were looking at before is going to be automatically updated so if I were to click here you can see that the task was immediately flagged as done and that is what we just did.

[03:46 - 05:43] We had the need to give immediate feedback to the user through a change in our UI so we encapsulated that logic into a small and very lean and maintainable component that only cares about that part of the status of the global state of the application and nothing else and it doesn't really need to interact with any other component. Another thing to remember is that client components can be nested within other components either server components or other client components but whatever component that is used inside a client component will immediately be bundled into the same code package essentially that gets sent to the client. You can mix server components and client components and we'll get to that in future videos. Just know that client components are going to be bundled with the required child script code to make them work essentially to be reacted to events or to even know on how to interact with the state so keep that in mind when you're creating and architecting your components. Something also interesting about these components is that the next year's is going to be using two different ways to render them. So the first time around the first page load these components are going to be rendered statically on the server and they're going to be delivered as static HTML for the initial rendering of the page. Immediately once that happens they're going to be hydrated which means that once the rest of the child script code is received on the client the client the react code on the client is going to attach all event listeners and everything needed for these components to become interactive again. So it's a two-step process essentially and it's also one of the reasons why server components were created to improve on that process whenever such interactivity is not needed.

[05:44 - 06:17] But again I'm getting ahead of myself we'll get to that in another video so don 't worry about it right now. So to sum it up client components mark a significant step into crafting interactive web applications especially with React and Next. By mixing client and server paradigms you achieve optimal performance, maintainability and user experience. In upcoming lessons we'll go deeper into how these components are going to be useful to you for specific sections of the projects that you're going to be building. So in the meantime keep coding and I 'll see you on the next one.