React useEffect pitfalls: caching, boilerplate, race conditions, and request waterfalls

I stopped using useEffect for data fetching. Here's why. For years, my React components looked like this: useEffect(() => { setLoading(true); fetch('/api/users') .then(res => res.json()) .then(data => setUsers(data)) .catch(err => setError(err)) .finally(() => setLoading(false)); }, []); Loading state. Error state. Race conditions. Cleanup functions. Stale closures. Every. Single. Component. Then I switched to React Query (TanStack Query) and deleted 40% of my state management code overnight. Here's what changed: → No more loading/error/data useState triplets → Automatic caching — same data across 10 components, 1 network request → Background refetching — users always see fresh data without spinners → Race condition handling — built in, not bolted on → Retry logic — automatic, configurable, zero custom code But here's what most tutorials won't tell you: React Query doesn't replace ALL useEffect calls. It replaces the ones you should never have written in the first place. useEffect is still perfect for: • Subscriptions (WebSocket, event listeners) • DOM synchronization • Third-party library integration The mistake is using useEffect as a "fetch on mount" hook. That was always a workaround, not a pattern. In my TypeScript projects, I enforce this with a simple ESLint rule: no fetch() inside useEffect. If you're fetching data, use a query hook. Period. The result? Components that are 50% shorter, easier to test, and actually work correctly with React 18+ concurrent features. What's your go-to data fetching approach in React? Still useEffect, or have you moved on? #React #TypeScript #ReactQuery #TanStackQuery #WebDevelopment #JavaScript #DeveloperProductivity #CleanCode

Read down below for the full Explination : 1. array.sort() → array.toSorted() ❌ array.sort() Mutates (changes) the original array Can cause hidden bugs in React state Not immutable-friendly ✅ array.toSorted() Returns a new sorted array Keeps original array untouched Safer for modern functional patterns 👉 In React, immutability = predictable UI. 2. JSON.parse(JSON.stringify(obj)) → structuredClone(obj) ❌ JSON trick Breaks Dates Breaks Maps/Sets Removes functions Fails with circular references ✅ structuredClone() Deep clones properly Supports complex data types Cleaner and faster 👉 Stop using the “hack”. Use the real API. 3. Promise.all() → Promise.allSettled() ❌ Promise.all() Fails immediately if ONE promise fails You lose other results ✅ Promise.allSettled() Waits for ALL promises Returns success + failure results Perfect for dashboards, multiple API calls 👉 More resilient apps. 4. indexOf() → findIndex() ❌ indexOf(value) Only works for exact matches Doesn’t work well with objects ✅ findIndex(callback) Can search with logic Works with objects More flexible Example: users.findIndex(user => user.id === 10) 👉 Cleaner + more expressive. #JavaScript #ModernJavaScript #WebDevelopment #FrontendDevelopment #CleanCode #ReactJS #SoftwareEngineering

🚀 Day 23 — Mastering Upward Data Flow in React In React, data flows downward by default — from parent to child via props. But scalable applications require something equally important: 👉 Upward data flow — sending data from a child component back to its parent. Today, I focused on mastering this pattern and applying it in a real project. 🔹 Understanding Upward Data Flow (Child ➝ Parent) Although it may seem indirect, the mechanism follows a clear and predictable pattern: ✅ The 4-Step Pattern 1️⃣ Define a Custom Event Prop The child receives a function as a prop (e.g., onCategoryChange). 2️⃣ Trigger the Event in the Child Inside the child component, a function is executed (often via a synthetic event like a button click) that calls the prop function and passes relevant data. 3️⃣ Handle the Event in the Parent The parent passes a handler function to the child. 4️⃣ Update Parent State The parent receives the data and updates its state, triggering a controlled re-render. This preserves React’s unidirectional data model while enabling interactive behavior. 🔹 Real-World Application — Fake Store Project 🛒 I applied this pattern in a project using the Fake Store API. Architecture overview: Parent component: manages state for category filters and search text Child component: triggers filtering events based on user interaction Parent re-renders child with updated filtered data This separation keeps: • State ownership centralized • Components reusable • Data flow predictable 🧠 Key Engineering Insight React applications scale well when: State lives at the correct hierarchy level Child components remain reusable and stateless where possible Communication patterns remain explicit and predictable Upward data flow is not a workaround — it is a deliberate architectural pattern. Onward to Day 24 🚀 💬 For frontend developers: How do you decide where state should live in a complex component tree? #ReactJS #FrontendDevelopment #ReactPatterns #SoftwareEngineering #WebArchitecture #JavaScript #100DaysOfCode #LearningInPublic

→ Most React devs make this mistake in forms… They create a new state for every input ❌ After building dashboards, multi-step forms, and filter panels — here’s the pattern that actually scales 👇 → Treat your form as data, not markup 💡 Define fields as config: const fields = [ { name: "email", label: "Email", type: "email", required: true }, { name: "role", label: "Role", type: "select", options: ["Admin", "User"] }, ]; → One state. One handler. const [formData, setFormData] = useState({}); const [errors, setErrors] = useState({}); const handleChange = (e) => { const { name, value } = e.target; setFormData(prev => ({ ...prev, [name]: value })); }; ⚡ Validation that scales: const validate = (name, value) => { const field = fields.find(f => f.name === name); if (field.required && !value) { setErrors(prev => ({ ...prev, [name]: `${field.label} is required` })); } }; → Why this works: → Add a field = 1 line change → No extra handlers → Works for 3 or 30 fields 🧠 Mental shift: → Stop thinking in inputs. Start thinking in schema. #ReactJS #Frontend #JavaScript #CleanCode #WebDevelopment

⚠️ This “clean” React code is a silent production bug. {data.length > 0 && data.map(...)} Looks fine in dev. Breaks in production. 💥 Here’s what actually goes wrong: ❌ data = undefined → crash ❌ data.length = 0 → renders “0” on UI 😳 ❌ No safety checks → unpredictable bugs 👉 What you should update: ✅ Replace short-circuit (&&) with ternary ✅ Add optional chaining → data?.map(...) ✅ Validate data → Array.isArray(data) ✅ Always add fallback UI ✅ Use proper keys (not index) 💡 Real example: Your API is slow → data is undefined → user sees a broken screen. 👉 Lesson: Clean code is not enough. Production-safe code is what matters. 💻 Check Image to understand much better and follow for more tips and learning 👨💻✍️ #ReactJS #Frontend #SoftwareEngineering #JavaScript #DevTips #Learning

React Query?? ‎ ‎Fetching data with React is generally a process that involves a lot of code. ‎ ‎You often need to use the “useEffect” hook in combination with “useState” to manage the fetched data. This requires a lot of boilerplate that we have to write in every component in which we want to fetch data. ‎ ‎Become a Medium member ‎React Query can help you cut down on the code you write when making network requests with React. All of this React code that we had to write before can be replaced with the hook “useQuery”. From it we get back all of the data that we need without having to declare a state variable: ‎ ‎However, making data fetching easier only covers a small slice of what React Query does. What makes it a very powerful library is that it caches (saves) requests that we make. So in many cases if we’ve requested data before, we don’t have to make another request, we can just read it from the cache. ‎ ‎This is immensely helpful because it cuts down repetition in our code, reduces the load we put on our API, and helps us manage our overall app state. If you pick any library to start adding to your projects today out of this list, make it React Query. ‎ ‎#reactjs #javascript #useEffect #useQuery #nextjs ‎

React Query?? ‎ ‎Fetching data with React is generally a process that involves a lot of code. ‎ ‎You often need to use the “useEffect” hook in combination with “useState” to manage the fetched data. This requires a lot of boilerplate that we have to write in every component in which we want to fetch data. ‎ ‎Become a Medium member ‎React Query can help you cut down on the code you write when making network requests with React. All of this React code that we had to write before can be replaced with the hook “useQuery”. From it we get back all of the data that we need without having to declare a state variable: ‎ ‎However, making data fetching easier only covers a small slice of what React Query does. What makes it a very powerful library is that it caches (saves) requests that we make. So in many cases if we’ve requested data before, we don’t have to make another request, we can just read it from the cache. ‎ ‎This is immensely helpful because it cuts down repetition in our code, reduces the load we put on our API, and helps us manage our overall app state. If you pick any library to start adding to your projects today out of this list, make it React Query. ‎ ‎#reactjs #javascript #useEffect #useQuery #nextjs ‎

React Query?? ‎ ‎Fetching data with React is generally a process that involves a lot of code. ‎ ‎You often need to use the “useEffect” hook in combination with “useState” to manage the fetched data. This requires a lot of boilerplate that we have to write in every component in which we want to fetch data. ‎ ‎Become a Medium member ‎React Query can help you cut down on the code you write when making network requests with React. All of this React code that we had to write before can be replaced with the hook “useQuery”. From it we get back all of the data that we need without having to declare a state variable: ‎ ‎However, making data fetching easier only covers a small slice of what React Query does. What makes it a very powerful library is that it caches (saves) requests that we make. So in many cases if we’ve requested data before, we don’t have to make another request, we can just read it from the cache. ‎ ‎This is immensely helpful because it cuts down repetition in our code, reduces the load we put on our API, and helps us manage our overall app state. If you pick any library to start adding to your projects today out of this list, make it React Query. ‎ ‎#reactjs #javascript #useEffect #useQuery #nextjs ‎

⚠️ A Common React Mistake That Slowly Breaks Applications One thing I keep noticing in many React codebases: Everything becomes global state. At first it feels convenient. Need the data somewhere? Just put it in global state. But over time this starts causing problems: • Components re-render more than necessary • Debugging becomes harder • State dependencies become unclear • Performance slowly degrades Not every piece of data needs to live globally. Sometimes the best architecture is simply: ✅ Local state where possible ✅ Lift state only when necessary ✅ Global state only for truly shared data Frontend architecture isn’t about adding tools. It’s about using the right level of complexity for the problem. Sometimes the best optimization is simply keeping state closer to where it belongs. Curious how others approach this — How do you decide what belongs in global state vs local state? #ReactJS #FrontendDevelopment #JavaScript #SoftwareEngineering #WebDevelopment

Still fetching data with useEffect in React? It's time to upgrade! 🚀 Managing server state is one of the biggest challenges in modern frontend — caching, deduplication, background refetching, race conditions. If you're choosing a data-fetching library, it usually comes down to these three: 🟦 TanStack Query — The Heavyweight Champion ✅ Granular cache control, optimistic updates, incredible DevTools, framework-agnostic (React, Vue, Svelte, Solid) ⚠️ Larger bundle (~13–16KB gz), steeper learning curve 🎯 Best for complex apps with heavy data-fetching needs. ⬛ SWR — The Lightweight Speedster ✅ Minimal API, stale-while-revalidate strategy, tiny bundle (~4–5KB gz), built by Vercel ⚠️ Less cache control, no official DevTools, React-only 🎯 Best for simpler apps, bundle-sensitive projects, or Next.js/Vercel ecosystems. 🟪 RTK Query — The Redux Companion ✅ Built into Redux Toolkit, seamless Redux integration, intuitive tag-based cache invalidation ⚠️ Requires Redux Toolkit setup, relies on Redux DevTools 🎯 Best for projects already using Redux or large enterprise apps 💡 TL;DR: 👉 Already using Redux? → RTK Query 👉 Need robust features & control? → TanStack Query 👉 Need something fast & lightweight? → SWR As even the Redux maintainers themselves recommend . if you're not already on Redux, just default to TanStack Query. You won't regret it. Which data-fetching library is your go-to in 2026? Drop it in the comments! 👇 #ReactJS #WebDevelopment #Frontend #JavaScript #TanStack #SWR #Redux #RTKQuery #SoftwareEngineering