Whenever you write an Effect, consider whether it would be clearer to wrap it in a custom Hook.
We shouldn’t need Effects very often, but only when we need to “step outside React” to synchronise with some external system or to do something React doesn’t have a built-in API for.
With time, the React team’s goal is to reduce the number of Effects in your app to the minimum by providing more specific solutions to more specific problems. Wrapping your Effects in custom Hooks makes it easier to upgrade your code when these solutions become available.
We need to fetch a user’s profile in two different components. How would you use a custom hook to handle that?
If you placed the fetch logic directly inside each component, what problems could arise?
What values would you return from the hook so the component can show loading, error, or data?
You added a custom hook that opens a WebSocket in a useEffect, but the connection is created multiple times on re‑render. How would you debug and fix it?
A form component uses a custom validation hook that runs on every keystroke and causes lag. How would you decide whether to keep the hook or refactor it?
When a custom hook depends on a React context, what trade‑offs do you consider regarding testability and coupling?
Design a reusable custom hook for infinite scrolling that works across several list components with different item renderers. What edge cases would you handle?
How would you ensure a custom hook that manages a global loading spinner doesn’t leak memory or retain stale closures in a large app?
If a team wants to replace several class components with functional ones using a shared custom hook, what migration strategy would you suggest to keep regressions low?
Our platform has dozens of custom hooks across many services. How would you set guidelines to decide when to create a new hook versus reusing existing utilities, considering maintainability and bundle size?
When moving from a monorepo to micro‑frontends, what impact does a proliferation of custom hooks have on shared state management, and how would you address it?
A legacy codebase heavily uses custom hooks that capture mutable refs. How would you evaluate refactoring them to improve type safety and future scalability?