Rahul R Jain’s Post

🧠 React Data Fetching: Old vs New (React 19) For years in React we fetched API data using useEffect. The flow looked like this: render → useEffect runs → fetch → setState → render again It worked… but it also caused: • loading state handling everywhere 😅 • UI flicker before data appears 👀 • race conditions on fast navigation ⚠️ • double API calls in Strict Mode 🔁 React 19 introduces a different idea using `use()` + Suspense ✨ Now React treats data as a *render dependency. If a component needs data, React simply waits for it before rendering ⏳ New flow: fetch → React waits → render once ⚡ Important mindset shift: useEffect → run something after UI appears (events, subscriptions, DOM) use() → UI cannot appear until data exists So instead of showing an empty component and updating later, React renders the UI only when it’s ready 🎯 In short: Old React: UI loads first, data comes later 🧩 New React: Data loads first, UI appears after 🚀 This isn’t just a syntax change — it’s an architecture change in how React thinks about rendering. #react #reactjs #frontenddevelopment #javascript #webdevelopment

🧠 React Data Fetching: Old vs New (React 19) For years in React we fetched API data using useEffect. The flow looked like this: render → useEffect runs → fetch → setState → render again It worked… but it also caused: • loading state handling everywhere 😅 • UI flicker before data appears 👀 • race conditions on fast navigation ⚠️ • double API calls in Strict Mode 🔁 React 19 introduces a different idea using `use()` + Suspense ✨ Now React treats data as a *render dependency. If a component needs data, React simply waits for it before rendering ⏳ New flow: fetch → React waits → render once ⚡ Important mindset shift: useEffect → run something after UI appears (events, subscriptions, DOM) use() → UI cannot appear until data exists So instead of showing an empty component and updating later, React renders the UI only when it’s ready 🎯 In short: Old React: UI loads first, data comes later 🧩 New React: Data loads first, UI appears after 🚀 This isn’t just a syntax change — it’s an architecture change in how React thinks about rendering. #react #reactjs #frontenddevelopment #javascript #webdevelopment

React 19 Just Changed Data Fetching — Here’s Why It Matters React 19 introduces a powerful new hook: use() — and it simplifies data fetching dramatically. What’s New ? You can now fetch data directly during render: const user = use(fetch("/api/user").then(res => res.json())); No useEffect. No useState. No manual loading logic. React pauses rendering using Suspense and continues once data is ready. The Old Way (Problem):- Previously, we had to: Render → run useEffect → fetch → update state → re-render This caused: Waterfall fetching Double renders Extra boilerplate Harder SSR support Repeated network requests It worked — but wasn’t efficient. What React 19 Solves:- Fetching starts during render Suspense handles loading UI Cleaner and smaller code Built-in request deduplication Better support for Server Components React shifts from: “Render → Fetch → Re-render” To: “Fetch while rendering → Render once with data” Does This Replace React Query? Not fully. React 19 improves how we fetch. React Query manages how server state behaves over time (caching, background refetching, optimistic updates, pagination, etc.). What’s your take — sticking with React Query or moving to use() ? #React19 #ReactJS #FrontendDevelopment #JavaScript #ReactHooks #TechTrends #WebPerformance #AI

🔁 Two-Way Data Binding vs React State – What’s the Difference? ⚛️ One of the most common questions I hear from developers transitioning between frameworks is about data binding vs state management. Here’s a simple breakdown 👇 🔁 Two-Way Data Binding (Seen in frameworks like Angular) Data flows in both directions UI updates the model automatically Model updates the UI automatically ✅ Faster to build simple forms ❌ Harder to debug at scale ❌ Can impact performance in large applications ⚛️ React State (One-Way Data Flow) (Used in React) Data flows in one direction UI changes trigger events State updates re-render the UI explicitly ✅ Predictable and easier to debug ✅ Scales well for large applications ✅ Better performance control 🆚 Quick Comparison 🔹 Two-Way Binding = Convenience 🔹 React State = Control & Predictability 🧠 Simple Analogy Two-Way Binding is like an automatic car 🚗 React State is like a manual car 🏎️ — more control, better performance 💡 Takeaway: If you’re building large, scalable applications, one-way data flow (React state) gives you clarity, performance, and maintainability. What’s your preference — Two-Way Binding or React State? 👇 Let’s discuss! #React #JavaScript #WebDevelopment #Frontend #SoftwareEngineering #Angular #StateManagement

import { useEffect, useState } from "react"; function Users() {  const [users, setUsers] = useState([]);  const [error, setError] = useState(null);  useEffect(() => {   fetch("https://lnkd.in/gEJ3JWfR")    .then(res => {     if (!res.ok) throw new Error("API Error");     return res.json();    })    .then(data => setUsers(data))    .catch(err => setError(err.message));  }, []);  if (error) return <p>{error}</p>;  return (   <ul>    {users.map(user => (     <li key={user.id}>{user.name}</li>    ))}   </ul>  ); } export default Users; 🧠 What’s happening: fetch() returns a Promise .then() handles resolved data .catch() handles failures React re-renders when state updates Why Promises matter in React 👇 ✅ Predictable API handling ✅ Clean loading & error states ✅ Better user experience ✅ Fewer race conditions Promises are the foundation. async/await is just syntax sugar on top. If you don’t understand Promises, you don’t fully understand React data flow. #ReactJS #JavaScript #Promises #APIs #FrontendDevelopment #WebDevelopment #AsyncProgramming

Most React devs have written this pattern at least once: component mounts → useEffect fires → fetch starts → data arrives → re-render It works... Until it doesn't. Here's what useEffect silently fails to handle for you, and why it matters. 🔴 No caching Every component mount sends a new request. Navigate away and come back? Another request — even if the data hasn't changed at all. 🔴 Boilerplate You need three useState calls just to track data, loading, and error. On every single fetch, in every single component. 🔴 Race conditions If the user navigates quickly, multiple fetches fire in parallel. The one that resolves last wins — even if it carries stale data. Good luck reproducing this one in dev. 🔴 Request waterfalls Parent fetches, renders children, children fetch. Each step waits for the previous one. The deeper the component tree, the slower the page. BUT ... React Query solves all four problems with a single hook. Look at the right side: same component, a fraction of the code. And out of the box you get: → Caching — same query, zero extra requests → Deduplication(multiple components, one fetch) → Background refetching on window focus → Race condition handling, automatically The key insight: useEffect is a synchronization tool. It was built to sync your component with external systems, not to serve as a data-fetching layer. It just happened to be the only option for a long time. React Query exists because data fetching deserves its own abstraction. #React #ReactQuery #WebDevelopment #Frontend #JavaScript

🚀 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

𝐈𝐟 𝐲𝐨𝐮'𝐫𝐞 𝐬𝐭𝐢𝐥𝐥 𝐰𝐫𝐞𝐬𝐭𝐥𝐢𝐧𝐠 𝐰𝐢𝐭𝐡 𝐚𝐧𝐲 𝐰𝐡𝐞𝐧 𝐦𝐚𝐩𝐩𝐢𝐧𝐠 𝐨𝐛𝐣𝐞𝐜𝐭 𝐩𝐫𝐨𝐩𝐞𝐫𝐭𝐢𝐞𝐬 𝐢𝐧 𝐓𝐲𝐩𝐞𝐒𝐜𝐫𝐢𝐩𝐭, 𝐲𝐨𝐮'𝐫𝐞 𝐦𝐢𝐬𝐬𝐢𝐧𝐠 𝐨𝐮𝐭. I've seen so many React components become any-land when trying to build reusable utilities that operate on object shapes. Like a generic Picker component that takes an array of objects and needs to extract a specific id or name field, but only if that field exists. The magic often lies in properly constraining your generics. Instead of `function getProperty<T>(obj: T, key: string)` (which loses all type safety for `key`), try `extends keyof T`. Example: ```typescript function pickProperty<T extends Record<string, any>, K extends keyof T>( items: T[], key: K ): T[K][] { return items.map(item => item[key]); } // Usage: interface User { id: string; name: string; email: string; } const users: User[] = [ /* ... */ ]; const userIds = pickProperty(users, 'id'); // Type: string[] // pickProperty(users, 'address'); // TS Error: 'address' does not exist on type 'User' ``` Here, `T extends Record<string, any>` ensures `T` is an object, and `K extends keyof T` makes sure `key` is a valid property of `T`. This gives you strong type inference and compiler errors where you need them. This pattern is a lifesaver for building type-safe, reusable data transformations in your React/Next.js applications, especially when dealing with API responses that share common structures. What's your go-to pattern for keeping object manipulations type-safe without falling back to any? Share your thoughts below! #TypeScript #React #FrontendDevelopment #Generics #WebDev

𝗥𝗲𝗮𝗰𝘁.𝗷𝘀 𝗣𝗮𝗿𝘁 𝟰 (𝟮𝟬𝟮𝟲): 𝗔𝗱𝘃𝗮𝗻𝗰𝗲𝗱 𝗛𝗼𝗼𝗸𝘀 𝗗𝗲𝗲𝗽 𝗗𝗶𝘃𝗲 🔥 Hi everyone! 👋 In Part 3, we covered the core hooks: useState, useEffect, and useRef. Today, let’s master the 𝗔𝗱𝘃𝗮𝗻𝗰𝗲𝗱 𝗛𝗼𝗼𝗸𝘀 that separate good React devs from great ones 1) useReducer (Complex State Logic) 𝗪𝗵𝗮𝘁 𝗶𝘁 𝗱𝗼𝗲𝘀: Manages state with a reducer function, like useState on steroids. Think of it like a traffic controller, actions go in, state updates are predictable. Key points:  • Best for multiple related state values  • Logic lives outside the component (easier testing)  • `dispatch(action)` instead of `setState(value)`  • Pairs well with useContext for global state 📌 Examples: Shopping cart, large forms, multi-step flows, undo/redo. 𝘂𝘀𝗲𝗦𝘁𝗮𝘁𝗲 𝘃𝘀 𝘂𝘀𝗲𝗥𝗲𝗱𝘂𝗰𝗲𝗿  • useState → simple values  • useReducer → complex transitions 2) useMemo (Expensive Computation Caching) 𝗪𝗵𝗮𝘁 𝗶𝘁 𝗱𝗼𝗲𝘀: Memoizes a computed value, recalculates only when dependencies change. Like a calculator with memory, don’t redo work unnecessarily. Use it for:  1. Expensive computations (filtering/sorting big lists)  2. Stable derived values  3. Preventing unnecessary recalculations Don’t overuse:  • It has overhead  • Profile first, optimize second 📌 Examples: Filtering 10k items, computing totals, chart data prep. 3) useCallback (Stable Function References) 𝗪𝗵𝗮𝘁 𝗶𝘁 𝗱𝗼𝗲𝘀: Returns a memoized function reference between renders. Why it matters: New function every render = child re-render. Use it when passing callbacks to memoized components. 𝘂𝘀𝗲𝗠𝗲𝗺𝗼 𝘃𝘀 𝘂𝘀𝗲𝗖𝗮𝗹𝗹𝗯𝗮𝗰𝗸:  • useMemo → caches a value  • useCallback → caches a function 📌 Examples: onClick handlers, API functions passed as props, debounced handlers. 4) useContext (Global State Without Prop Drilling) Let's components access shared data without passing props through every level. Think Wi-Fi connects without cables. 3-step pattern:  1. createContext()  2. Provider  3. useContext() Common uses:  • Theme  • Auth state  • Language  • Feature flags Tip: Combine with useReducer for a lightweight global store. 𝗣𝗲𝗿𝗳𝗼𝗿𝗺𝗮𝗻𝗰𝗲 𝗧𝗶𝗽𝘀   • React.memo — skip re-renders if props don’t change  • useCallback + React.memo — stable props  • useMemo — skip heavy recalculations  • React.lazy() + Suspense — code splitting  • Use stable, unique keys in lists  • 𝗚𝗼𝗹𝗱𝗲𝗻 𝗿𝘂𝗹𝗲: 𝗠𝗲𝗮𝘀𝘂𝗿𝗲 𝗯𝗲𝗳𝗼𝗿𝗲 𝗼𝗽𝘁𝗶𝗺𝗶𝘇𝗶𝗻𝗴.  • 𝗥𝗲𝗮𝗰𝘁 𝗗𝗲𝘃𝗧𝗼𝗼𝗹𝘀 𝗣𝗿𝗼𝗳𝗶𝗹𝗲𝗿 𝗶𝘀 𝘆𝗼𝘂𝗿 𝗯𝗲𝘀𝘁 𝗳𝗿𝗶𝗲𝗻𝗱. 𝙽̲𝚎̲𝚡̲𝚝̲ ̲𝙿̲𝚘̲𝚜̲𝚝̲:̲ ̲𝙲̲𝚞̲𝚜̲𝚝̲𝚘̲𝚖̲ ̲𝙷̲𝚘̲𝚘̲𝚔̲𝚜̲,̲ ̲𝙱̲𝚞̲𝚒̲𝚕̲𝚍̲𝚒̲𝚗̲𝚐̲ ̲𝚁̲𝚎̲𝚞̲𝚜̲𝚊̲𝚋̲𝚕̲𝚎̲ ̲𝙻̲𝚘̲𝚐̲𝚒̲𝚌̲ ̲(̲𝚞̲𝚜̲𝚎̲𝙵̲𝚎̲𝚝̲𝚌̲𝚑̲,̲ ̲𝚞̲𝚜̲𝚎̲𝙳̲𝚎̲𝚋̲𝚘̲𝚞̲𝚗̲𝚌̲𝚎̲,̲ ̲𝚞̲𝚜̲𝚎̲𝙻̲𝚘̲𝚌̲𝚊̲𝚕̲𝚂̲𝚝̲𝚘̲𝚛̲𝚊̲𝚐̲𝚎̲,̲ ̲𝚞̲𝚜̲𝚎̲𝙵̲𝚘̲𝚛̲𝚖̲)̲ #ReactJS #JavaScript #ReactHooks #FrontendDevelopment #LearnReact

Day 4 — Props: Passing Data Between Components in React 🚀 In React, Props (short for properties) are how components talk to each other. Think of props like arguments you pass to a function. 🔹 What are Props? Props are read-only inputs to a component They are passed from Parent ➝ Child A child component cannot modify props They make components reusable & predictable 📌 React follows one-way data flow to keep apps easy to debug. 🔹 Simple Real-Life Analogy Imagine a TV remote 📺 The remote (parent) sends commands The TV (child) receives and uses them The TV can’t change the remote That’s exactly how props work. 🔹 Basic Example Parent Component JavaScript function App() { return ( <User name="Prashanth" role="Frontend Developer" /> ); } Child Component function User(props) { return ( <h2> Hi, I’m {props.name} and I work as a {props.role} </h2> ); } ✅ Output: Hi, I’m Prashanth and I work as a Frontend Developer 🔹 Destructuring Props (Cleaner Way) function User({ name, role }) { return <h2>{name} — {role}</h2>; } ✔️ Cleaner ✔️ More readable ✔️ Preferred in real projects 🔹 Props Make Components Reusable ♻️ <User name="Prashanth" role="Angular Developer" /> <User name="Rahul" role="React Developer" /> <User name="Anita" role="UI Designer" /> 👉 Same component 👉 Different data 👉 Zero duplicate code 🔹 Important Rules to Remember ❌ Props are immutable (read-only) ❌ Child should NOT modify props ✅ Use state if data needs to change ✅ Props = data flow ✅ State = data control 🔹 Why Props Matter? Keeps UI predictable Improves component communication Makes apps scalable Encourages clean architecture 🧠 One-Line Summary Props allow data to flow from parent to child, making React components reusable, predictable, and easy to maintain. #React #ReactTips #LearnReact Want Day 5 — State vs Props next? 😄