useEffect

𝐈𝐬 𝐲𝐨𝐮𝐫 `𝐮𝐬𝐞𝐄𝐟𝐟𝐞𝐜𝐭` 𝐫𝐮𝐧𝐧𝐢𝐧𝐠 𝐰𝐡𝐞𝐧 𝐢𝐭 𝐬𝐡𝐨𝐮𝐥𝐝𝐧'𝐭? 𝐓𝐡𝐞 𝐜𝐮𝐥𝐩𝐫𝐢𝐭 𝐦𝐢𝐠𝐡𝐭 𝐛𝐞 𝐦𝐨𝐫𝐞 𝐬𝐮𝐛𝐭𝐥𝐞 𝐭𝐡𝐚𝐧 𝐲𝐨𝐮 𝐭𝐡𝐢𝐧𝐤. I just spent a frustrating hour debugging a seemingly random data refetch in a React component, only to trace it back to a non-primitive dependency in my `useEffect` array. When you pass an object or a function created inside your component directly into `useEffect`'s dependency array, React performs a reference equality check. Even if the contents of your object or the logic of your function haven't changed, its reference is new on every render. This forces your effect to re-run unnecessarily. Here's the common trap: ```javascript // 🚨 Problematic: 'config' object reference changes on every render const MyComponent = ({ id }) => { const config = { userId: id, status: 'active' }; useEffect(() => { fetchData(config); }, [config]); // 💥 Effect re-runs even if 'id' hasn't changed // ... }; ``` A cleaner, more performant way is to stabilize those references. For configuration objects, `useMemo` is your friend: ```javascript // ✅ Solution: 'memoizedConfig' reference is stable as long as 'id' is const MyComponent = ({ id }) => { const memoizedConfig = useMemo(() => ({ userId: id, status: 'active' }), [id]); useEffect(() => { fetchData(memoizedConfig); }, [memoizedConfig]); // ... }; ``` This prevents wasted renders and unnecessary side effects, keeping your app snappier and less buggy. It's often the small details in `useEffect` that lead to the biggest headaches! Have you ever battled a similar `useEffect` dependency bug? What was your fix? #ReactJS #FrontendDevelopment #JavaScript #WebDev #ReactHooks

React 19's `useActionState` hook is the simplest way to cut form boilerplate in half. If you're still writing React 18-style form handlers with separate `useState` calls for loading, errors, and results — this hook consolidates all of that into one line. Key points: 🔹 **One hook replaces three `useState` calls** — `useActionState` returns `[state, dispatch, isPending]` in a single call 🔹 **No `e.preventDefault()` needed** — wire the action to `<form action={formAction}>` and React handles the rest 🔹 **Automatic pending state** — `isPending` is managed by React, no manual `setIsPending(true/false)` 🔹 **Works with Server Functions** — seamless integration with React Server Components 🔹 **Multiple independent actions** — use multiple `useActionState` calls in one component, each managing its own state Before (React 18): ```jsx const [loading, setLoading] = useState(false); const [error, setError] = useState(null); const [result, setResult] = useState(null); // handleSubmit with try/catch/finally ``` After (React 19): ```jsx const [state, formAction, isPending] = useActionState( async (prev, formData) => { // Your async logic return { success: true }; }, initialState ); ``` The hook is stable in React 19 and ready for production. Full deep dive with code examples here: https://lnkd.in/eHMp_Z-X What's your experience been? Have you migrated to `useActionState` yet? #react #javascript #webdevelopment #frontend #react19

useState × 4. onChange × 4. try/catch. isPending. That's the boilerplate every React form has shipped with for years. React 19 quietly deleted all of it. The new shape is two things: - An Action: an async function that takes (prevState, formData) and returns next state - useActionState(action, initial): gives you [state, formAction, isPending] And the form becomes: <form action={formAction}> What disappears: - useState for every input (uncontrolled inputs + FormData) - onChange handlers - gone entirely - try/catch in the component (the Action returns success or error) - Manual isPending tracking (the hook hands it to you) What you write instead: - One async function (the Action) - One hook call (useActionState) - A <form action=...> with inputs that have a name attribute The mental model shift: Forms used to be controlled state machines you wired up by hand. Now they're a function (the Action) plus a state container (useActionState). Bonus: tag the same Action with "use server" and it runs on the server. The form keeps working without client-side JS. What's the most boilerplate-heavy form you've shipped? Curious how much React 19 would shrink it. #React #React19 #Frontend #WebDev #JavaScript #LearnInPublic

🚀 5 React Mistakes I Made as a Beginner (And How to Fix Them) When I first started building with React, I made a lot of mistakes that slowed me down and introduced bugs I couldn't explain. Here are 5 of the most common ones — and how to fix them: ❌ #1 — Not cleaning up useEffect Forget to return a cleanup function? Hello, memory leaks. ✅ Always return a cleanup for timers, event listeners, and subscriptions. ❌ #2 — Using index as a key in lists This breaks React's reconciliation and causes weird UI bugs. ✅ Always use a unique ID from your data as the key prop. ❌ #3 — Calling setState directly inside render This creates an infinite re-render loop. ✅ Keep state updates inside event handlers or useEffect only. ❌ #4 — Fetching data without handling loading and error states Your UI breaks or shows nothing while data loads. ✅ Always manage three states: loading, error, and success. ❌ #5 — Putting everything in one giant component Hard to read, hard to debug, impossible to reuse. ✅ Break your UI into small, focused, reusable components. These mistakes cost me hours of debugging. I hope sharing them saves you that time. If you found this helpful, feel free to repost ♻️ — it might help another developer on their journey. 💬 Which of these mistakes have you made? Drop a comment below! #React #JavaScript #WebDevelopment #Frontend #MERNStack #ReactJS #100DaysOfCode #CodingTips #Developer

I used to think performance optimization is for advanced developers… So I ignored it. Focused only on building features. But during one project, I noticed: Slow loading Unnecessary re-renders Heavy components That’s when it clicked. 👉 Performance is not optional anymore Now I focus on: • Smaller components • Optimized rendering • Clean logic The biggest learning: A fast app is always better than a complex one. What do you prioritize more: Features or performance? #ReactJS #WebPerformance #FrontendDeveloper #JavaScript

🔯 You can finally delete <Context.Provider> 👇 For years, the Context API introduced a small but persistent redundancy. We defined a Context object, yet we couldn't render it directly-we had to access the.Provider property every single time. 🔯 React 19 removes this requirement. ❌ The Old Way: UserContext.Provider It often felt like an implementation detail leaking into JSX. Forget Provider, and your app might silently fail or behave unexpectedly. ✅ The Modern Way: <UserContext> The Context object itself is now a valid React component. Just render it directly. Why this matters ❓ 📉 Less Noise - Cleaner JSX, especially with deeply nested providers 🧠 More Intuitive - Matches how we think: "wrap this in UserContext" 💡Note: Note: <Context.Consumer> is also largely dead in favor of the use hook or useContext. Starting in React 19, you can render <SomeContext> as a provider. In older versions of React, use <SomeContext.Provider>. 💬 Have you tried this in your project? 💬 React 18 or 19 — what are you using? 🔗 Learn More: React Context Docs: https://lnkd.in/dbVWdc-C #React #JavaScript #WebDevelopment #Frontend #React19 #ModernReact #ReactHook #CodingLife #DeveloperJourney #SoftwareDeveloper

Stop writing anonymous useEffect functions. Name them. This is one of the smallest changes you can make in React — and one of the most underrated. Most of us write this: useEffect(() => { fetchUser(id); }, [id]); But you can do this: useEffect(function fetchUserOnIdChange() { fetchUser(id); }, [id]); Same behavior. Completely different debugging experience. Here's why it matters: 🔍 Stack traces become readable When something goes wrong inside an effect, your browser's stack trace will show fetchUserOnIdChange instead of just useEffect. You'll know exactly which effect blew up — no more hunting through 8 anonymous functions. 🧠 Self-documenting code A named function is a contract. It tells the next developer (or future you at 11pm) why this effect exists, not just what it does. syncFormWithLocalStorage communicates more than any comment ever could. ⚡ React DevTools clarity The React profiler and DevTools display effect names. When you're profiling performance, named effects let you immediately identify what's running, when, and how often. 🤝 Easier code reviews Reviewers can scan for useEffect(function loadDashboardMetrics and instantly understand intent. No need to read the entire body just to grasp the purpose. The rule of thumb I follow: If an effect is longer than 3 lines or runs conditionally, it gets a name. No exceptions. It takes 2 seconds to type. It saves 20 minutes of debugging. Small habits compound. This is one worth picking up. 🚀 What's a small React habit that's made a big difference for your team? Drop it in the comments 👇 #React #JavaScript #WebDevelopment #FrontendEngineering #CleanCode #ReactJS #SoftwareEngineering

React keeps evolving but one thing hasn’t changed: Clean, maintainable components still matter more than trendy patterns. There’s so much noise around tools, libraries and “must-know” tricks that it’s easy to overlook simple patterns that make day to day code better. So switching gears a little from my usual reflective posts today I wanted to share something practical from my experience, 5 React patterns I keep coming back to in real projects that help reduce component bloat, improve readability, and keep code easier to scale. Inside the carousel: 1. Early returns over nested conditions 2. Custom hooks for cleaner logic 3. Object maps over condition chains 4. When not to overuse useMemo 5. Splitting UI from business logic None of these are flashy. They’re just small patterns that compound. Save it for your next React refactor if useful. ⚛️♻️ #ReactJS #FrontendDevelopment #JavaScript #SoftwareEngineering #WebDevelopment #CleanCode #FullStackDeveloper

I struggled with this React concept more than I expected… 👇 👉 Why are my API calls running twice? ⚙️ What you’ll notice You open your network tab and suddenly see this: api/me → called twice api/roles → called twice api/permissions → called twice Just like in the screenshot 👇 Same request, duplicated… again and again. ⚙️ What’s actually happening In React (development mode), if your app is wrapped in Strict Mode, React will run effects twice on purpose. useEffect(() => { fetch("/api/users") .then(res => res.json()) .then(setUsers); }, []); Even though it looks like it should run once… it doesn’t (in dev). 🧠 What’s going on under the hood React basically does a quick cycle: mount → unmount → remount Why? To catch hidden side effects To check if cleanup is handled properly To make sure your logic doesn’t break on re-renders So if your API call runs twice, React is just making sure your code can handle it. 💡 The important part This only happens in development Production behaves normally (runs once) Your side effects should be safe to run multiple times 🚀 Final thought If your network tab looks “noisy” like the screenshot, it’s not React being broken — it’s React being careful. And once you understand this, debugging becomes a lot less confusing. #React #Frontend #JavaScript #WebDevelopment #ReactJS #SoftwareEngineering

𝐓𝐡𝐢𝐧𝐤𝐢𝐧𝐠 `React.memo` 𝐦𝐚𝐤𝐞𝐬 𝐲𝐨𝐮𝐫 𝐜𝐨𝐦𝐩𝐨𝐧𝐞𝐧𝐭𝐬 𝐩𝐞𝐫𝐟𝐞𝐜𝐭𝐥𝐲 𝐩𝐞𝐫𝐟𝐨𝐫𝐦𝐚𝐧𝐭? 𝐓𝐡𝐢𝐧𝐤 𝐚𝐠𝐚𝐢𝐧. Many of us reach for `React.memo` to prevent unnecessary re-renders in child components. And it works wonders... most of the time. But here's the catch: `React.memo` performs a shallow comparison of props. If you're passing object, array, or function props, even if their internal values haven't changed, a new reference is created on every parent re-render. This new reference makes `React.memo` think the prop has changed, leading to an unwanted re-render of your memoized child component. ```javascript // Parent component re-renders: const data = { id: 1, name: 'Item' }; // New object reference! <MemoizedChild item={data} /> // Or with a function: const handleClick = () => console.log('clicked'); // New function reference! <MemoizedChild onClick={handleClick} /> ``` The solution? Pair `React.memo` with `useCallback` for functions and `useMemo` for objects/arrays. ```javascript // In Parent component: const memoizedData = useMemo(() => ({ id: 1, name: 'Item' }), []); const memoizedHandleClick = useCallback(() => console.log('clicked'), []); <MemoizedChild item={memoizedData} onClick={memoizedHandleClick} /> ``` This ensures your props maintain the same reference across renders, allowing `React.memo` to truly shine. It's a small detail, but crucial for optimizing complex applications. How aggressively do you memoize in your React apps? Share your go-to strategies! #React #ReactJS #FrontendDevelopment #WebPerformance #JavaScript