# Introduction It's easy to do a job with one tool; easy, but not **necessary** convenient. Yet, there are other tools that can do same thing at the end of the day. With great power, comes great responsibilities they say and frontend developers have this **great power :)**. Simply because a set of tools can do be used for similar operations, doesn't mean they should be used randomly, or without reasonable consideration. It's this same way I misused the features of Next.js when I started using it. However, with my hunger for, and readings about best practices, I have acquired a good knowledge of the feature, and know when and how to apply them. ## Client Component In case you're not aware, React is simply a library that allows for building user interfaces. One of its key feature is its component-based architecture. A component is an independent pieces of UI. > React is a library, not a framework. Next.js is a react framework. Before the introduction of server components performing asynchronous operations within a component was tricky, you'd have to `fetch` your data in a `useEffect` hook. React provides something called **hooks**. My understanding of hooks is that its React's way of managing states and triggering renders when they change. ```JSX // The way it should be function MyComponent() { let count = 0; // we should be able to increment count, right? return <>

{" "} {count}

} ``` The above code wouldn't work as expected. A React function component is a JavaScript function with markup. During rendering, React does not track changes to regular variables like `count` because React's rendering system is immutable. This means that updates to `count` won't trigger a re-render of the component. React hooks, such as `useState`, solve this problem by providing a way to manage state and trigger re-renders when the state changes. ```JSX // Unfortunately function MyComponent() { const [count, setCount] = React.useState(0) // not really without this. return <>

{" "} {count}

} ``` > React puts interactivity first while still using the same technology: a React component is a JavaScript function that you can sprinkle with markup. - [react.dev](https://react.dev/learn/your-first-component#:~:text=React%20puts%20interactivity%20first%20while%20still%20using%20the%20same%20technology%3A%20a%20React%20component%20is%20a%20JavaScript%20function%20that%20you%20can%20sprinkle%20with%20markup.) I think the little introduction to React is fine, but what does the term **client component** means? If we're considering the term **client**, then it means the bigger picture includes **server**. Client components are React component, that runs on the client-side. Every web application is served through a server. In web development terms, the client usually refers to the web browser, which can execute JavaScript code. Client components are bundled JavaScript code that gets executed in your browser. While the server hosting an application can send HTML code for the browser to render, there are also cases where the rendered markup needs to be manipulated dynamically. With that being said, here is when you will need to use client component: - **For Interactivity**: React hooks don't work with server components. Remember that React hooks are for managing states and triggering re-render when the state changes. Any piece of the UI that requires a state, will be a client component. States cannot be managed on the server. > Hmmm, there could be a way to have states on the server, idk, but I guess it'll require a lot of polling between the client and the server. Unnecessary complications. - **If you need the Browser API**: APIs like `localStorage`, `document` etc. are provided by your browser, so the bundled client component can only access them there. If your component needs to work with `localStorage`, or needs to use the document to manipulate an element, that component must be a client component. - **Your Form Should Be A Client Component**: Form fields like ``, `