Optimize Scroll Events with Intersection Observer API

Clean up your React components with Object State When building a form, it's tempting to create a new useState hook for every single input. It feels intuitive at first, but it quickly leads to a mess of declarations that are hard to maintain. The Problem: ❌ Multiple setState calls for a single entity. ❌ Harder to map data for API requests. ❌ Excessive "visual noise" in your component. The Solution: ✅ Group related data into a single object. This keeps your data structure consistent with your backend and simplifies your logic. // ❌ BAD: Fragmented State function RegistrationForm() { const [name, setName] = useState(''); const [email, setEmail] = useState(''); const [password, setPassword] = useState(''); /* ... */ } // ✅ GOOD: Grouped State function RegistrationForm() { const [form, setForm] = useState({ name: '', email: '', password: '' }); /* ... */ } 💡 Pro Tip: Use the name attribute on your inputs to update the entire form with a single handler: setForm({ ...form, [e. target .name]: e. target .value }) One function to rule them all. Clean, scalable, and much easier to debug. 🚀 How do you handle forms? Do you stick to useState, or are you team useReducer for complex logic? #React #SoftwareEngineering #ReactDesignPatterns #ReactJS #CleanCode #Frontend #WebDevelopment #CodingTips #itsmacr8

Effect Synchronization in React: Write Better Code, Use Fewer useEffects 👨💻 Today, I explored something important that many of us overlook while working with React — how useEffect can silently introduce bugs, memory leaks, and unnecessary complexity if not used correctly. One of the most common mistakes in React codebases is overusing the useEffect hook. Effect synchronization is about keeping side effects aligned with a component’s state, props, and lifecycle. Since React’s rendering model is asynchronous (and Strict Mode runs effects twice in dev), poorly synchronized effects can cause bugs, memory leaks, and performance issues. 🔹 Why effect synchronization matters 🔁 Components can re-render multiple times ⚠️ Effects can capture stale state (closures) 🧠 Missing cleanup leads to memory leaks 🔍 Strict Mode exposes unsafe effects early 🔹 Key principles to follow ✅ Use the dependency array correctly ✅ Avoid stale closures ✅ Always clean up effects ✅ Sync only with external systems 🔹 Avoid these common anti-patterns ❌ Copying props into state ❌ Storing derived data in state ❌ Fetching data on mount with useEffect ❌ Updating the DOM inside useEffect 🔹 Better approaches 🧩 Compute derived values during render ⚡ Use use, SWR, or React Query for data fetching 🧠 Use useMemo when necessary 🔌 Use useLayoutEffect for DOM-related updates 💡 Mental model to remember 🪜 useEffect is an escape hatch, not a default tool 🔗 Use it only when synchronizing React with external systems Mastering effect synchronization leads to: ✨ Cleaner components ⚡ Better performance 🐞 Fewer bugs 🧠 Easier reasoning about state #React #Frontend #WebDevelopment #JavaScript #ReactHooks #CleanCode #SoftwareEngineering

"𝗖𝗼𝗻𝘁𝗲𝘅𝘁 𝗶𝘀 𝘀𝗹𝗼𝘄" I hear this a lot. But it’s not true. Context isn’t slow; 𝗥𝗲𝗰𝗼𝗻𝗰𝗶𝗹𝗶𝗮𝘁𝗶𝗼𝗻 is just doing exactly what it was told to do. To understand why your app is lagging, you have to look BHS at how React handles updates. 𝗧𝗵𝗲 𝗥𝗲𝗰𝗼𝗻𝗰𝗶𝗹𝗶𝗮𝘁𝗶𝗼𝗻 𝗧𝗿𝗮𝗽: When a 𝗖𝗼𝗻𝘁𝗲𝘅𝘁.𝗣𝗿𝗼𝘃𝗶𝗱𝗲𝗿 value changes, React’s "Difference Engine" (Reconciliation) kicks in. Because 𝘂𝘀𝗲𝗖𝗼𝗻𝘁𝗲𝘅𝘁 lacks a built-in 𝘀𝗲𝗹𝗲𝗰𝘁𝗼𝗿 𝗺𝗲𝗰𝗵𝗮𝗻𝗶𝘀𝗺, it doesn't know about "parts" of an object. If your Context holds 20 pieces of data and you change just one, 𝗲𝘃𝗲𝗿𝘆 𝘀𝗶𝗻𝗴𝗹𝗲 𝗰𝗼𝗺𝗽𝗼𝗻𝗲𝗻𝘁 subscribing to that context is forced to re-render. It skips 𝗥𝗲𝗮𝗰𝘁.𝗺𝗲𝗺𝗼. It ignores your optimizations. It’s a top-down broadcast that can turn a simple toggle into a performance bottleneck. 🧸𝗭𝘂𝘀𝘁𝗮𝗻𝗱 doesn’t fight the React tree, it moves state outside of it. Instead of relying on React’s fiber tree to pass data down, Zustand uses a closure-based "pub/sub" model 𝗧𝗵𝗲 𝗕𝗛𝗦 𝗗𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝗰𝗲: 𝗗𝗶𝗿𝗲𝗰𝘁 𝗨𝗽𝗱𝗮𝘁𝗲𝘀: Zustand holds a list of listeners. When state changes, it only pokes the specific components that need to know. 𝗦𝗺𝗮𝗿𝘁 𝗦𝗲𝗹𝗲𝗰𝘁𝗼𝗿𝘀: By using 𝘂𝘀𝗲𝗦𝘁𝗼𝗿𝗲(𝘀𝘁𝗮𝘁𝗲 => 𝘀𝘁𝗮𝘁𝗲.𝘂𝘀𝗲𝗿), you tell Zustand: "Only wake me up if the user changes." If the theme changes? Your component doesn't even enter the render phase. 💡𝗨𝘀𝗲 𝗖𝗼𝗻𝘁𝗲𝘅𝘁 It’s perfect for low-frequency data like Themes, Translations, or static Service instances. 𝗨𝘀𝗲 𝗭𝘂𝘀𝘁𝗮𝗻𝗱 for "State Management." It’s built for high-frequency updates, complex logic, and performance at scale #ReactJS #Zustand #WebDevelopment #FrontendEngineering #JavaScript #SoftwareArchitecture

Stop using useEffect to sync your data. 🛑 When I first started handling complex state in React, I fell into a common trap. 1. I had a list of data (users). 2. I had a filter (searchQuery). 3. I used useEffect to update a third state called filteredUsers. It felt logical at the time. "When the query changes, update the list." But this is actually a "Sync Nightmare." 👻 ❌ The Trap (Left Image): Every time the user types, the component renders once for the input change... and then renders again because the useEffect updates filteredUsers. Even worse: If the users prop updates quickly, the filteredUsers state might lag behind, showing stale data for a split second. ✅ The Better Way (Right Image): Don't "sync" data. Derive it. Just filter the array directly in the render body. const filteredUsers = users.filter(...) "But isn't filtering expensive?" Then use useMemo. This tells React: "Only re-calculate this list if users or searchQuery actually changed." Why this wins: 1. Zero Lag: The data is always correct, instantly. 2. Performance: You save an entire render cycle. 3. Simplicity: You deleted a useState and a useEffect. The best code is the code you delete. 🗑️ Do you use useEffect for filtering, or have you switched to useMemo? 👇 #React #ReactJS #JavaScript #FrontendDevelopment #WebDevelopment #CleanCode #Performance #BestPractices #SoftwareEngineering #DeveloperExperience #DevCommunity #CodingTips #Tech

𝟵𝟬% 𝗼𝗳 "𝗙𝗿𝗼𝗻𝘁𝗲𝗻𝗱 𝗘𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴" 𝗶𝘀 𝗷𝘂𝘀𝘁 𝗺𝗼𝘃𝗶𝗻𝗴 𝗱𝗮𝘁𝗮 𝗳𝗿𝗼𝗺 𝗣𝗼𝗶𝗻𝘁 𝗔 𝘁𝗼 𝗣𝗼𝗶𝗻𝘁 𝗕 𝘄𝗶𝘁𝗵𝗼𝘂𝘁 𝗯𝗿𝗲𝗮𝗸𝗶𝗻𝗴 𝘁𝗵𝗲 𝗨𝗜. 🤷♂️ We spend hours debating 𝗥𝗲𝗮𝗰𝘁 vs. 𝗡𝗲𝘅𝘁.𝗷𝘀 or 𝗧𝗮𝗶𝗹𝘄𝗶𝗻𝗱 vs. 𝗖𝗦𝗦. But users only care about: 1️⃣ 𝗦𝗽𝗲𝗲𝗱 — Does it load before they lose interest?⚡  2️⃣ 𝗔𝗰𝗰𝗲𝘀𝘀𝗶𝗯𝗶𝗹𝗶𝘁𝘆 — Can everyone actually use it? ♿  3️⃣ 𝗥𝗲𝗹𝗶𝗮𝗯𝗶𝗹𝗶𝘁𝘆 — Does it stay functional on a spotty 5G connection? 📶 𝗧𝗼𝗼𝗹𝘀 𝗰𝗵𝗮𝗻𝗴𝗲. Every few months, there’s a new "must-have" library. But if you master the 𝗳𝘂𝗻𝗱𝗮𝗺𝗲𝗻𝘁𝗮𝗹𝘀 - clean 𝗝𝗮𝘃𝗮𝗦𝗰𝗿𝗶𝗽𝘁, semantic 𝗛𝗧𝗠𝗟, and modern 𝗖𝗦𝗦—you become 𝗳𝘂𝘁𝘂𝗿𝗲-𝗽𝗿𝗼𝗼𝗳. The framework is just the 𝗱𝗲𝗹𝗶𝘃𝗲𝗿𝘆 𝘃𝗲𝗵𝗶𝗰𝗹𝗲. The logic is where the real value lives. 💬 𝗔𝗴𝗿𝗲𝗲 𝗼𝗿 𝗱𝗶𝘀𝗮𝗴𝗿𝗲𝗲? Is frontend getting 𝘁𝗼𝗼 𝗰𝗼𝗺𝗽𝗹𝗲𝘅, or are these tools necessary for the modern web? Let’s talk in the comments! 👇 #JavaScript #WebDevelopment #Frontend #SoftwareEngineering #CodingTips

Why useEffect Is Used Less in Modern React (and What Replaces It) useEffect is not deprecated. It’s not “bad”. But in modern React, we’ve learned to use it more intentionally. Earlier, useEffect was often used for: 1. Fetching data 2. Syncing one state with another 3. Running logic after every render Over time, this caused problems. The core issue with useEffect useEffect runs after render and is meant for side effects — things that happen outside React. When we use it to: 1. Manage data 2. Derive state 3. Control UI logic we introduce: 1. Extra renders 2. Complex dependency arrays 3. Hard-to-debug behavior In many cases, the effect exists only to “fix” state that could have been correct during render. What modern React encourages instead 1. Derive state during render If a value can be calculated from props or state, compute it directly instead of syncing it with an effect. This keeps components predictable and easier to reason about. 2. Use dedicated data-fetching tools (like TanStack Query) Data fetching is not just a side effect — it involves caching, retries, refetching, and background updates. Libraries like TanStack Query handle this declaratively, without manual effects or state management. 3. Server Components & Server Actions In frameworks like Next.js, data can be fetched on the server and sent ready to render. This removes the need for client-side effects for initial data loading and improves performance. 4. Suspense for async UI Suspense allows React to manage loading states at the rendering level instead of inside effects. When useEffect is still the right choice useEffect is still essential when interacting with things outside React: 1. Browser APIs 2. Subscriptions (WebSocket, events) 3. Timers 4. Analytics That’s exactly what it was designed for. Key takeaway Modern React doesn’t remove useEffect. "It reduces misuse by providing better, more specialized tools. If something can be derived, fetches data, or belongs on the server — useEffect is probably not the best tool." #ReactJS #FrontendDevelopment #ModernReact #JavaScript #TanStackQuery #WebDevelopment #ReactBestPractices #SoftwareEngineering

When asked “How would you optimize frontend performance?”, jumping straight to techniques like memoization, code splitting, or caching is actually the wrong/stupid answer. 🚫 Optimization is not a checklist. 🚫 It’s not about showing how many buzzwords you know. ✅ A logical answer starts with finding the root cause. Before optimizing, you should: 1. Measure performance using tools like Lighthouse, DevTools, or React Profiler 2. Identify bottlenecks: slow API calls, unnecessary re-renders, large bundles, blocking resources 3. Understand why the page is slow, not just how to fix it Only after diagnosis do optimization techniques make sense: 1. Memoization if re-renders are the issue 2. Code splitting if bundle size is the problem 3. Caching if repeated network calls are slowing things down 💡 Premature optimization wastes time. 🎯 Targeted optimization delivers results. Tools like Lighthouse and Google for Developers Chrome DevTools make it clear that performance is about measurement first, not guesswork. As Addy Osmani often highlights, performance optimization starts with understanding real bottlenecks. Performance optimization is a debugging process, not a flex of techniques. #Frontend #WebPerformance #React #JavaScript #EngineeringMindset #CleanCode

In React 19, stop managing your server State like it’s client State In React, not all "state" is created equal. Mixing them up leads to redundant API calls, stale data and a bloated codebase. Here is how to draw the line: Client-side state (UI-related data, lives entirely in the browser) Examples: Form inputs, toggles, modal visibility and theme switch. Goal: Fast, synchronous updates to the UI. Tools: React Context, Zustand or Redux. Server-side state (data that comes from an API or backend) Examples: User profiles, product lists, and analytics. Goal: Caching, synchronization, background updates and handling loading/error states. Tools: - TanStack Query: The gold standard for remote data. It handles caching and deduplication out of the box with zero boilerplate. - RTK Query: The logical choice if you’re already in the Redux Toolkit ecosystem. - createAsyncThunk: Best for custom async workflows where you need manual control over how the response affects multiple state slices. Pitfall: you manage caching and loading logic manually. Common scenarios: 1) UI/Local Behavior - Zustand / Context 2) Heavy API usage (No Redux) - TanStack Query 3) Heavy API usage (Using Redux) - RTK Query 4) Complex, custom async logic - createAsyncThunk If you find yourself manually writing isLoading and isError booleans for every API call, it’s time to switch to a dedicated data-fetching library. Thanks to JavaScript Mastery, Hitesh Choudhary, RoadsideCoder.com, Traversy Media, Web Dev Simplified for sharing such valuable content for Frontend production-grade applications. #ReactJS #React19 #ReactHooks #TanStackQuery #ReduxToolkit #ReduxThunk #ReactContext #WebDevelopment #JavaScript

The Biggest Performance Win I Had Wasn’t Writing Code — It Was Deleting It. We were chasing performance issues the usual way — optimizing logic, tweaking renders, caching APIs. Then I opened the bundle analyzer. The app was shipping ~2.1MB of JavaScript on first load. Only about 38% of it was actually used on the landing flow. That changed how I looked at “optimization.” Instead of adding more clever code, we focused on shipping less code. What we did: 1. Tree Shaking → 420KB saved Unused utilities and dead exports were still bundled. Moving to strict ES modules and proper imports cut hundreds of KB instantly. 2. Lazy Loading → 600KB moved out of initial load Dashboards, modals, and rarely used flows were loaded only when users reached them. 3. Code Splitting → TTI improved by ~32% One giant bundle became feature-based chunks instead of a “download everything” strategy. 4. Dependency Audit → 310KB removed Replaced heavy libraries with native APIs and lighter alternatives. Found 3 packages nobody even remembered adding. Final outcome: • Bundle: 2.1MB → 870KB • First Contentful Paint: 2.8s → 1.4s • Time To Interactive: 4.6s → 3.1s • Mobile Lighthouse: 58 → 89 Same features. Same UI. Completely different user experience. My biggest takeaway as an engineer: Performance isn’t about how smart the code is — it’s about how little of it reaches the user. Real impact often comes from removing complexity, not adding it. #JavaScript #WebPerformance #Frontend #Engineering #Optimization #CleanCode #React #Tech

🚀  React Performance Concepts: useCallback vs useMemo While working on real-world React projects, I realized that performance issues don’t come from React itself — they come from unnecessary re-renders. That’s where useCallback and useMemo actually help (when used correctly). 🔹 useCallback (Memoizing Functions) In React, functions are recreated on every render. When these functions are passed as props to child components, it can trigger unwanted re-renders, especially in large component trees. 👉 I use useCallback only when a function is passed to a memoized child component or used in dependency arrays. Real use case: Button click handlers Form event handlers Callback props in reusable components 🔹 useMemo (Memoizing Values) Sometimes components re-render even when the derived data hasn’t changed. If the calculation is expensive (filtering, sorting, aggregations), it affects performance. 👉 I use useMemo to cache computed values so React recalculates them only when dependencies change. Real use case: Filtering large lists Sorting data tables Calculating totals or derived state ⚡ Simple Difference (Practical View) useCallback → remembers a function useMemo → remembers a value Both are performance optimization tools, not mandatory hooks. #ReactJS #FrontendDevelopment #JavaScript #ReactHooks #WebDevelopment #PerformanceOptimization #UseCallback #UseMemo #FrontendEngineer #LearningInPublic #ReactDeveloper