Hooks Pattern
Teaches React Hooks for reusing stateful logic across components. Use when extracting shared behavior like form handling, subscriptions, or side effects into reusable custom hooks.
- Skill ID
- patternsdev/skills/hooks-pattern
- Publisher
- patternsdev
- Repository
- skills
- Installs
- 0
- Files
- 1
- License
- MIT
- Synced
- Sep 23, 2026
Open any RiverX project, open the Skills panel in the chat, and search for this identifier. The files are fetched from the source repository at install time.
patternsdev/skills/hooks-patternInstalls these files- SKILL.md
What this skill tells the agent
Hooks Pattern
Table of Contents
- When to Use
- Instructions
- Details
- Source
React 16.8 introduced a new feature called **Hooks**. Hooks make it possible to use React state and lifecycle methods, without having to use an ES2015 class component.
Although Hooks are not necessarily a design pattern, Hooks play a very important role in your application design. Many traditional design patterns can be replaced by Hooks.
When to Use
- Use this when you need to add state or lifecycle behavior to functional components
- This is helpful for extracting and reusing stateful logic across multiple components
- Use this instead of class components for cleaner, more composable code
Instructions
- Use
useStatefor local state anduseEffectfor side effects in functional components - Create custom hooks (prefixed with
use) to encapsulate and share reusable logic - Follow the Rules of Hooks: only call hooks at the top level and only in React functions
- Avoid unnecessary
useEffect— compute derived state directly in the component body - Let the React Compiler handle memoization instead of manual
useMemo/useCallbackwhere possible
Details
Class components
Before Hooks were introduced in React, we had to use class components in order to add state and lifecycle methods to components. A typical class component in React can look something like:
class MyComponent extends React.Component {
/* Adding state and binding custom methods */
constructor() {
super()
this.state = { ... }
this.customMethodOne = this.customMethodOne.bind(this)
this.customMethodTwo = this.customMethodTwo.bind(this)
}
/* Lifecycle Methods */
componentDidMount() { ...}
componentWillUnmount() { ... }
/* Custom methods */
customMethodOne() { ... }
customMethodTwo() { ... }
render() { return { ... }}
}A class component can contain a state in its constructor, lifecycle methods such as componentDidMount and componentWillUnmount to perform side effects based on a component's lifecycle, and custom methods to add extra logic to a class.
Although we can still use class components after the introduction of React Hooks, using class components can have some downsides! Let's look at some of the most common issues when using class components.
Understanding ES2015 classes
Since class components were the only component that could handle state and lifecycle methods before React Hooks, we often ended up having to refactor functional components into a class components, in order to add the extra functionality.
In this example, we have a simple div that functions as a button.
function Button() {
return <div className="btn">disabled</div>;
}Instead of always displaying disabled, we want to change it to enabled when the user clicks on the button, and add some extra CSS styling to the button when that happens.
In order to do that, we need to add state to the component in order to know whether the status is enabled or disabled. This means that we'd have to refactor the functional component entirely, and make it a class component that keeps track of the button's state.
export default class Button extends React.Component {
constructor() {
super();
this.state = { enabled: false };
}
render() {
const { enabled } = this.state;
const btnText = enabled ? "enabled" : "disabled";
return (
<div
className={`btn enabled-${enabled}`}
onClick={() => this.setState({ enabled: !enabled })}
>
{btnText}
</div>
);
}
}In this example, the component is very small and refactoring wasn't a such a great deal. However, your real-life components probably contain of many more lines of code, which makes refactoring the component a lot more difficult.
Besides having to make sure you don't accidentally change any behavior while refactoring the component, you also need to understand how ES2015 classes work. Why do we have to bind the custom methods? What does the constructor do? Where does the this keyword come from? It can be difficult to know how to refactor a component properly without accidentally changing the data flow.
Restructuring
The common way to share code among several components, is by using the Higher Order Component or Render Props pattern. Although both patterns are valid and a good practice, adding those patterns at a later point in time requires you to restructure your application.
Besides having to restructure your app, which is trickier the bigger your components are, having many wrapping components in order to share code among deeper nested components can lead to something that's best referred to as a _wrapper hell_. It's not uncommon to open your dev tools and seeing a structure similar to:
<WrapperOne>
<WrapperTwo>
<WrapperThree>
<WrapperFour>
<WrapperFive>
<Component>
<h1>Finally in the component!</h1>
</Component>
</WrapperFive>
</WrapperFour>
</WrapperThree>
</WrapperTwo>
</WrapperOne>The _wrapper hell_ can make it difficult to understand how data is flowing through your application, which can make it harder to figure out why unexpected behavior is happening.
Complexity
As we add more logic to class components, the size of the component increases fast. Logic within that component can get tangled and unstructured, which can make it difficult for developers to understand where certain logic is used in the class component. This can make debugging and optimizing performance more difficult.
Lifecycle methods also require quite a lot of duplication in the code.
Although a component may be small, the logic within the component can already be quite tangled. Whereas certain parts are specific for the counter logic, other parts are specific for the width logic. As your component grows, it can get increasingly difficult to structure logic within your component, find related logic within the component.
Besides tangled logic, we're also duplicating some logic within the lifecycle methods. In both componentDidMount and componentWillUnmount, we're customizing the behavior of the app based on the window's resize event.
Hooks
It's quite clear that class components aren't always a great feature in React. In order to solve the common issues that React developers can run into when using class components, React introduced React Hooks. React Hooks are functions that you can use to manage a components state and lifecycle methods. React Hooks make it possible to:
- add state to a functional component
- manage a component's lifecycle without having to use lifecycle methods such as
componentDidMountandcomponentWillUnmount - reuse the same stateful logic among multiple components throughout the app
First, let's take a look at how we can add state to a functional component, using React Hooks.
State Hook
React provides a hook that manages state within a functional component, called useState.
Let's see how a class component can be restructured into a functional component, using the useState hook. We have a class component called Input, which simply renders an input field. The value of input in the state updates, whenever the user types anything in the input field.
class Input extends React.Component {
constructor() {
super();
this.state = { input: "" };
this.handleInput = this.handleInput.bind(this);
}
handleInput(e) {
this.setState({ input: e.target.value });
}
render() {
<input onChange={handleInput} value={this.state.input} />;
}
}More from patternsdev
Use this skill in a project
Open any RiverX project, search the Skills panel for patternsdev/skills/hooks-pattern, and install it in one click.
