5 Useful Hooks People Often Forget About

I think most developers who work or have worked with React.js definitely know about useState, useEffect, and useMemo and understand how they work. In general, there are more hooks — some of them are situational, and some are worth knowing and understanding as well, because in real-life situations they help solve certain tasks with minimal effort or simply make the code cleaner. Below, I would like to mention 5 more hooks that will definitely be useful and explain them.

1. useRef

This hook is quite well known because it is often used to store a reference to a DOM element. In general, the useRef hook creates a stable container for storing anything. It persists between renders, can be mutated without triggering a re-render, and does not reset when the component updates. It is useful for: storing props or state values; certain control tools such as timers, WebSocket, AbortController; caching objects or class instances; lifecycle flags. Bad use cases: when changing the value should update the UI; for business data that participates in rendering; as a workaround for poor state architecture.

2. useLayoutEffect

Overall, the useEffect and useLayoutEffect hooks are quite similar to each other, share the same principles of work and dependencies, but they are executed at different times, and that is their real difference. useLayoutEffect runs right before the UI appears on the screen, unlike its sibling, which runs after that moment. This hook is perfect for: measuring DOM element sizes, calculating positions, synchronizing scroll positions, or avoiding layout shifts. For API calls, logic not tied to the DOM, or cases where there are no visual jumps in the interface — it’s better not to use it.

3. useCallback

The useCallback hook is usually used as soon as developers notice strange behavior of functions after re-renders. The root of the problem lies in JavaScript itself and, accordingly, in React.js. On every render, functions that are defined are recreated, and they are passed to other places by reference. As a result, after a re-render, the reference may still point to the old function with old data, while the new one exists somewhere else… This behavior often breaks dependencies in useEffect, memo components, or third-party libraries that require referential equality. This is exactly the problem this hook solves — it allows not only updating a specific function reference, but also triggering changes in other places that depend on this function. It is appropriate when: a function is in a dependency array, a callback is passed to a memoized component, or event handlers are used in lists. It should not be used in situations: when it’s a local handler without dependencies, when the component is not optimized with memo, or just in case. The main thing to remember — useCallback optimizes only the reference, not the render speed!

4. useImperativeHandle

By nature, React is declarative, but sometimes we still need to write imperative code. useImperativeHandle allows you to break declarativity in a proper way. It is important to note that it should be used only for UI, not for data. Typical scenarios: focus(), blur(), scrollTo(), resetting internal state, integrations with third-party libraries. It should not be used: for regular interaction between components, instead of props or callbacks, or for business logic.

5. Custom hooks

When it feels like React is incomplete and lacks many things, and libraries don’t provide what you want, you can always extend the standard set of hooks with your own. It’s a great opportunity to wrap a certain piece of logic into a custom hook that perfectly fits your needs, doing exactly what you want to see, with an always-appropriate feature set and parameters. From my experience, this is a wonderfully flexible tool for any kind of solutions and requirements. It greatly helps to encapsulate side effects, complex state, or repeated logic. It becomes truly justified in situations when: you have logic that is repeated in multiple places; the component becomes hard to read; there is a clear business or UI task. I would not recommend using it for one-off cases, for hiding very large chunks of logic, or when the code cannot be understood without separately reading the hook implementation.

In conclusion, these hooks are not must-haves for every project, and they won’t do all the work for you or instantly make the project perfect. They are simply tools for solving specific problems or tasks, allowing you to: reduce chaos in components, improve behavior predictability, lower maintenance costs, solve tasks more flexibly, and scale the project more easily.

It’s important to understand that using all hooks is not a marker of a good project, but using them correctly and understanding them is a marker of a good developer.

We have a great team at Swan Software Solutions. To find out more about how our team could help your team with a custom solution of other technology needs, schedule a free assessment.