Creating Custom React Hooks

Part 1: What is a Custom Hook?

Before we build one, let's establish a clear mental model for when a custom hook is the right tool for the job.

As the video succinctly states:

1. To reuse JSX/markup, create a Component.
2. To reuse simple JavaScript logic (without React features), create a utility function.
3. To reuse stateful logic involving React hooks, create a Custom Hook.

A custom hook is, at its core, a JavaScript function with two key properties:

1. Its name must start with the word use (e.g., useFormInput). This is a convention that React's linter uses to enforce the Rules of Hooks.
2. It can call other hooks (e.g., useState, useEffect, or even other custom hooks).

This ability to call other hooks is what makes a custom hook "React-aware," distinguishing it from a plain utility function. It can tap into React's features like state, effects, and context.

Let's see how this works by extracting logic from a component.

The key takeaway from this example is how the extraction changes the component code. Instead of focusing on the implementation (setting up state, adding and cleaning up event listeners), the component can now declaratively express its intent:

const isOnline = useOnlineStatus();

This makes the component cleaner, easier to read, and decouples it from the low-level browser APIs.

Part 2: Implementing a Custom Hook

Now that we understand the "why," let's build a simple custom hook from scratch. We'll start with a common UI pattern: toggling a value.

Let's recap the structure of the useToggle hook:

1. Define the function: function useToggle(initialValue = false) { ... }
2. Use React primitives: const [value, setValue] = useState(initialValue);
3. Encapsulate the logic: const toggle = () => setValue(prev => !prev);
4. Return the public API: return [value, toggle];

Returning Values: Array vs. Object

The useToggle hook returns an array, just like useState. This is a common pattern, but not the only one. You can also return an object.

Here is a summary of the trade-offs:

• Returning an Array (e.g., [value, toggle]):

  • Pro: Allows the consumer to name the destructured variables freely (e.g., const [isDark, toggleTheme] = useToggle();). This is great for avoiding naming collisions when using the same hook multiple times.
  • Con: The consumer must rely on the order of the elements. Getting the order wrong can lead to subtle bugs.

• Returning an Object (e.g., { value, toggle }):

  • Pro: The order doesn't matter, and the names are explicit, which can make the code more self-documenting.
  • Con: Renaming requires more verbose syntax (e.g., const { value: isDark, toggle: toggleTheme } = useToggle();).

The convention is to use an array when the hook is analogous to useState (returning a value and a setter). For hooks that return multiple, distinct values, an object is often clearer.

Part 3: Under the Hood - How Do Hooks Really Work?

Your interest in the underlying mechanics is key here. Hooks seem magical, but they are built on two simple concepts: JavaScript closures and arrays.

1. Closures: A closure gives a function access to its "lexical scope" (the variables that were in scope when it was created), even when the function is executed outside that original scope. When you call useState, React creates a state variable and a setter function. That setter function "closes over" the internal state storage for your component, allowing it to modify it later.

2. Arrays: On the initial render of your component, React creates an array to store the state for each hook call. On subsequent renders, React walks through this array. The first call to useState gets the state from hooks[0], the second call gets it from hooks[1], and so on.

This array-based implementation is precisely why the Rules of Hooks exist:

• Rule 1: Only Call Hooks at the Top Level. If you call a hook inside a condition, loop, or nested function, the number of hook calls might change between renders. This would throw off the array indexing, causing React to retrieve the wrong state for a given hook.
• Rule 2: Only Call Hooks from React Functions. This ensures that hooks are only ever called within a component (or another hook) that has this internal array of state.

This "array-based" model demystifies hooks entirely. A custom hook isn't a special construct to React. When React renders your component, it just sees a flat list of primitive hook calls coming from both your component and any custom hooks you use.

Part 4: Sharing Logic, Not State

This is one of the most important concepts to grasp about custom hooks.

Let's say two different components both call useToggle(). Do they share the same true/false state? The answer is no.

Custom hooks share stateful logic, but not state itself.

Every call to a custom hook is completely independent and gets its own isolated state. When ComponentA calls useToggle(), it gets its own useState instance inside. When ComponentB calls useToggle(), it gets a completely separate useState instance.

Part 5: A More Advanced, Type-Safe Custom Hook

Let's build a more practical, real-world hook: useLocalStorage. This hook will synchronize a piece of React state with the browser's localStorage. This is a perfect example because it involves both useState (for the value) and useEffect (to handle the side effect of writing to localStorage).

Given your experience with TypeScript, we can also make this hook fully type-safe using generics.

The use of generics here (function useLocalStorage<T>(...)) is a powerful technique. It allows you to create a single hook that can work with any data type (string, number, object, etc.) while still providing full type safety and autocompletion in your editor, preventing a whole class of bugs.

Practice Challenge

Now it's your turn to apply these concepts. Let's adapt the useCounter challenge from the React documentation.

Your task:
Create a custom hook named useCounter.

1. It should accept an initialValue and a step value as arguments.
2. It should manage a count state, initialized with initialValue.
3. It should return an object containing:
   • The current count.
   • An increment function.
   • A decrement function.
   • A reset function.
4. Use this hook in a component to display the count and buttons to control it.

Think about the structure: you'll need useState to hold the count and you'll return an object with the value and the manipulator functions.

Conclusion

In this lesson, we demystified custom hooks, revealing them as a logical extension of React's core principles rather than a magical feature.

Key Takeaways:

• Purpose: Custom hooks allow you to extract and reuse stateful logic (logic that uses other hooks like useState or useEffect) from your components.
• Convention: They are JavaScript functions whose names must start with use.
• Mechanism: They work because of JavaScript closures (to "remember" state) and React's internal array-based state management, which requires a stable hook call order (the Rules of Hooks).
• Core Principle: Custom hooks share stateful logic, but each call to a hook creates its own independent state.
• Implementation: You can design their API to return values in an array (for flexibility) or an object (for clarity).

What's Next?

We've now seen how to encapsulate and reuse logic. But what about sharing the state itself across many components that are far apart in the component tree? Passing props down through many layers, known as "prop drilling," can become cumbersome.

In our next lesson, we will tackle this exact problem by exploring the Context API. We will see how it provides a way to pass data through the component tree without having to pass props down manually at every level, and we'll compare when to use Context versus lifting state up.