React useEffect: when to use, when to avoid

I used to put everything inside useEffect… Until one broken component changed how I think about React. 👀 When I first learned React, useEffect felt like a superpower. Something changed? → useEffect. Need to update a value? → useEffect. Something not working? → Add another dependency. It worked… until it really didn't. One day I was debugging a small component. Nothing complex on the surface. But it had: → Multiple effects fighting each other → Derived state stored AND recalculated → Unexpected re-renders on every tick → Dependency warnings I kept ignoring I sat back and asked: "Why is a 50-line component this painful?" The answer hit me hard. 💡 I was using useEffect as a catch-all. And it was silently making everything harder. Here's the mental model that changed everything: 01. Value computable from props or state? → Calculate it during render. Don't store it again. 02. Logic triggered by a button click? → Put it in the event handler. Not an effect. 03. Just filtering or transforming data? → Do it inline. Render is free. useEffect exists for one purpose — syncing with things outside React: ✦ API calls ✦ Subscriptions ✦ Timers ✦ DOM manipulation ✦ External libraries / WebSockets That's it. The list is short intentionally. The moment I started respecting that boundary… My components became: ✅ Cleaner to read ✅ Easier to debug ✅ More predictable ✅ Faster to ship Sometimes writing better React means writing less useEffect. The best refactor I ever did was deleting three effects — and replacing them with nothing at all. Have you ever refactored a component and removed half your effects? Drop your "aha moment" below 👇 I'd love to read it. #React #ReactJS #JavaScript #FrontendDevelopment #CleanCode #WebDevelopment #SoftwareEngineering #LearningJourney

  • graphical user interface, text, application

To view or add a comment, sign in

Explore content categories