Reading · ASP.NET Zero Blog

In React, custom hooks when used correctly are tools that reduce code duplication, improve readability, and simplify complex logic. However, in many projects, after a certain point, the following statements start to appear:

What exactly does this hook do?
Why is changing this hook so risky?
Why do I need to look at three hooks for a simple change?

At this point, the problem is usually not React itself, but incorrect abstraction of custom hooks.

In this article, we’ll examine when custom hooks truly add value, when they become a burden, and how to strike the right balance.

What Is the Real Purpose of Custom Hooks?

Let’s clarify the core purpose first. Custom hooks exist to:

Share repeated logic
Make components more readable
Isolate state and behavior that are independent of the UI

In other words, the goal is:

Code sharing + readability + clear responsibility

If a custom hook does not provide at least one of these, it should be questioned.

Unnecessary Abstraction

One of the most common issues is creating abstractions before repetition actually exists.

Example of premature abstraction

const useInput = (initialValue: string) => {
  const [value, setValue] = useState(initialValue);
  const onChange = (e) => setValue(e.target.value);
  return { value, onChange };
};

At first glance, this may seem reasonable. But if the project has only a single input:

The code does not get shorter
Readability does not improve
The hook creates additional cognitive load

At this point, the hook becomes an extra layer rather than a solution.

A simpler alternative

const [value, setValue] = useState("");

Core principle: If a piece of logic is not truly used in at least two different places, writing a custom hook is often a premature decision.

Over Generalized Hooks

Another common problem is over generalizing hooks with the idea that “we’ll use this everywhere later.”

A hook that grows over time

const useFetch = ({
  url,
  method,
  headers,
  body,
  autoFetch,
  onSuccess,
  onError,
}) => {
  // too many conditions
};

Initially, this hook may look powerful. But over time:

The number of parameters increases
Its behavior becomes harder to predict
A small change affects many places

As a result:

Even if the hook is reusable
Readability decreases
The cost of change increases

A healthier approach

Designing hooks with a narrow scope:

const useUser = (userId) => {
  const [user, setUser] = useState(null);
  useEffect(() => {
    fetchUser(userId).then(setUser);
  }, [userId]);
  return user;
};

This hook:

Has a clear responsibility
Is easy to understand
Is safer to modify

Readability vs. Reusability

This is the most critical balance point with custom hooks. Not every reusable piece of code is automatically better code.

Usage that hurts readability

const {
  state,
  handlers,
  computed,
  flags
} = useComplexFormLogic();

For someone reading this code:

What the hook does is unclear
Where the state comes from and what each handler affects is not obvious
Debugging takes longer

A readability first approach

const form = useLoginForm();

const { email, password, isValid, submit } = useLoginForm();

Here:

The hook’s purpose is clear
The usage remains simple
The component clearly communicates its intent

Custom Hooks That Hide Components

Poorly designed hooks can make the flow inside a component invisible.

Problematic structure

const Component = () => {
  useMagicHook();
  return <UI />;
};

Here:

It’s unclear where state is managed
When effects run is uncertain
Debugging becomes difficult

A more transparent approach

const Component = () => {
  const { data, isLoading } = useUsers();
  if (isLoading) return <Spinner />;
  return <UserList data={data} />;
};

With this usage:

Data flow is readable
Component behavior is clear
The hook supports the component instead of hiding it

Questions to Ask Before Writing a Custom Hook

Asking the following questions before writing a custom hook can save significant time:

Will this logic really be used in more than one place?
Does this abstraction make the code more readable, or more mysterious?
Does the hook have a single, clear responsibility?
How many components will be affected if this hook changes?

Often, this single question is enough:

“Would this code be more understandable if it stayed inside the component?”

When Are Custom Hooks an Advantage?

Custom hooks create real value when:

There are complex combinations of state and side effects
The same behavior is repeated across multiple components
UI independent logic can be extracted
Components become simpler as a result

When Do They Become a Burden?

Custom hooks become a burden when:

Single use logic is abstracted
Overly generalized APIs are created
Readability is sacrificed for reusability
Debugging becomes harder

In conclusion, custom hooks are one of React’s most powerful abstraction tools. But when used incorrectly, they make code more complex and fragile instead of simpler.

For a healthy approach:

Avoid premature abstraction
Design hooks with narrow, clear responsibilities
Prioritize readability over reusability

This leads to more sustainable React projects in the long run.

You May Want to Take a Look

If you’re working on larger React codebases, having a clear architectural baseline can make abstraction decisions like custom hooks much easier to manage over time.

ASP.NET Zero’s React setup is one example of this approach:

When Are Custom Hooks an Advantage in React, and When Do They Become a Liability?