I’m debugging a React app for a client who insists the page should update “instantly” when users click a button.
I’m knee-deep in state variables, loading flags, try-catch blocks, and a mental breakdown.
My useEffect
Looks like a spaghetti monster mated with a JSON dump.
Then it hits me: Why the hell am I writing this boilerplate over and over again?
That night, I built the one hook that changed everything: useAsync()
.

Edited by me
The Nightmare That Birthed a Hook
You’ve probably lived this too. Fetching data? Here comes a mess of:
const [data, setData] = useState(null);
const [loading, setLoading] = useState(false);
const [error, setError] = useState(null);
useEffect(() => {
setLoading(true);
fetch(url)
.then((res) => res.json())
.then(setData)
.catch(setError)
.finally(() => setLoading(false));
}, [url]);
Gross. Repetitive. Bug prone.
So I ripped it out. Abstracted it. And gave it a new home:
Say Hello to useAsync()
Here’s what it looks like:
const { data, error, loading, run } = useAsync();
useEffect(() => {
run(() => fetchDataFromAPI());
}, []);
Or even better:
const { data, loading, error } = useAsync(() => fetchDataFromAPI(), []);
Clean. Declarative. Sexy.
No more duplicating loading state logic.
No more 8 lines of async wrappers per component.
Just pass your function. The hook handles the ugly parts.
What It Does (Under the Hood)
The hook accepts an async function, executes it, and tracks:
loading
: boolean (self-explanatory)error
The caught error objectdata
: the resolved value
It handles cancellation (yep, no memory leaks from zombie fetches). And you can trigger it on mount or manually via .run()
.
Here’s the core idea:
function useAsync(fn, deps = []) {
const [data, setData] = useState(null);
const [error, setError] = useState(null);
const [loading, setLoading] = useState(false);
const run = useCallback(async () => {
setLoading(true);
setError(null);
try {
const result = await fn();
setData(result);
} catch (err) {
setError(err);
} finally {
setLoading(false);
}
}, deps);
useEffect(() => {
if (fn) run();
}, [run]);
return { data, error, loading, run };
}
Why You’ll Want It Too
Let’s be honest.
Frontend work is already chaotic.
We juggle user events, server responses, global state, and UX edge cases like a caffeinated octopus.
So anything that:
- Reduces repeated patterns
- Makes components cleaner
- Handles loading/error logic once and forever
…is worth tattooing on your IDE.
This hook turned my janky useEffect
-graveyards into clean, readable, business-logic-focused components.
But Wait — Why Not React Query or SWR?
Great tools. Love ’em.
Use them on bigger apps. But sometimes?
You just need a lightweight custom hook.
No config. No caching. No dependency injection. Just pure async logic control.
Think: internal dashboards, admin panels, MVPs. Places where simplicity wins.
This hook is my go-to in those cases. And it never lets me down.
Reality — This Hook Saves You From Yourself
Because let’s be real: it’s not just about code reusability. It’s about,
- Preventing bugs when you forget to reset
loading
- Avoiding nested try-catch hell
- Making junior devs say, “Whoa, that’s clean.”
It’s a form of self-care. The React version of drinking enough water.
Finally, You Deserve Clean Code
If you’re writing async logic in React and not abstracting it, you’re wasting time and sanity.
useAsync()
Is a tiny hook with big benefits. Make it. Customize it. Use it.
Hell, tattoo it on your forehead if you must.
What’s your go-to hook?
Have you built your own useAsync
variant?
Still clinging to useEffect
spaghetti?
Drop a comment. Start a flame war. Or just clap if you felt the same pain.
Let’s talk hooks.
Comments
Post a Comment