React 19: Server State vs Client State Management

💾 LocalStorage & SessionStorage in JavaScript – Store Data Without a Database Did you know your browser can store data even after refresh — without any backend? JavaScript provides two powerful storage options: localStorage → persists even after browser restart sessionStorage → clears when the tab is closed Perfect for saving user preferences, tokens, UI state, etc. 🧠 When Should You Use Browser Storage? Remember logged-in user (non-sensitive data) Save theme (dark/light mode) Store cart items temporarily Prevent unnecessary API calls 🚀 Why This Matters No server needed for small persistence Improves performance & UX Easy state management for frontend apps ⚠️ Best Practice Never store: ->Passwords ->Sensitive tokens ->Confidential user data Browser storage is not secure — it’s just convenient. #JavaScript #LocalStorage #SessionStorage #Frontend #WebDevelopment #Coding #InterviewPrep

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

React 19 just killed the useEffect data fetching headache! 🤯 For years, fetching data required a mess of useState, useEffect, and complex dependency arrays to avoid infinite loops and UI flickers. React 19 changes the game with the use() hook. The "Before" vs. "After": Before: Data fetching happened after rendering; you managed states and effects manually. Now (React 19): Data fetching happens during rendering. UI and data stay perfectly in sync. 🚀 Key Benefits of the use() Revolution: Zero Boilerplate: No more useEffect or local state just to store API results. No More Flickering: Eliminates the "loading → data" transition flicker. Built-in Error Handling: If a Promise fails, React automatically forwards it to the nearest ErrorBoundary no more try/catch messes. Automatic Refetching: Changing an input (like a userId) cancels the old Promise and runs a new one automatically. React 19 turns asynchronous data into a first-class part of rendering. It’s less code, less setup, and more predictable behavior. What’s your favorite React 19 feature so far? Let’s discuss below! 👇 #ReactJS #React19 #FrontendDevelopment

🚀 Controlled vs Uncontrolled Components in React When handling forms in React, we often use either Controlled or Uncontrolled components. The difference is about who manages the input data. 🔵 Controlled Component A controlled component is an input field whose value is managed by React state. 👉React becomes the single source of truth. Example: import { useState } from "react"; function ControlledForm() { const [name, setName] = useState(""); return ( <input type="text" value={name} onChange={(e) => setName(e.target.value)} /> ); } Here ●'useState' stores the input value. ●Every time the user types, 'onChange' updates the state. ●The input always displays the value from React state. ✅ Best for validation, dynamic UI updates, and complex forms. 🟠 Uncontrolled Component An uncontrolled component stores its data in the DOM, not in React state. 👉 React accesses the value only when needed using 'useRef'. Example: import { useRef } from "react"; function UncontrolledForm() { const nameRef = useRef(); const handleSubmit = () => { alert(nameRef.current.value); }; return ( <> <input type="text" ref={nameRef} /> <button onClick={handleSubmit}>Submit</button> </> ); } Here ●The input manages its own value internally. ●'useRef' is used to access the value when the button is clicked. ●React does not track every keystroke. ✅ Best for simple forms or quick implementations. 💡 Difference: ■Controlled → React controls the data. ■Uncontrolled → DOM controls the data. Understanding this concept helps in building cleaner, more predictable, and scalable React applications. #ReactJS #FrontendDevelopment #JavaScript #WebDevelopment #ReactLearning

⚡ 𝗥𝗲𝗮𝗰𝘁 𝗖𝗮𝗰𝗵𝗶𝗻𝗴 𝗔𝗣𝗜 𝗗𝗮𝘁𝗮 (𝗥𝗲𝗮𝗹-𝗪𝗼𝗿𝗹𝗱 𝗣𝗮𝘁𝘁𝗲𝗿𝗻) In my last few posts, I shared about: • Pagination • Retry logic • Infinite Scroll Today I want to talk about one thing I recently focused on while building React apps 👇 𝗖𝗮𝗰𝗵𝗶𝗻𝗴 𝗔𝗣𝗜 𝗱𝗮𝘁𝗮 ❓ 𝗪𝗵𝘆 𝗶𝘀 𝗰𝗮𝗰𝗵𝗶𝗻𝗴 𝗶𝗺𝗽𝗼𝗿𝘁𝗮𝗻𝘁? When we don’t use caching: – The same API gets called again and again – Network calls increase – UI feels slower than it should ✅ 𝗦𝗼 𝘄𝗵𝗮𝘁 𝗶𝘀 𝗔𝗣𝗜 𝗰𝗮𝗰𝗵𝗶𝗻𝗴? In simple words: We store the API response somewhere and reuse it instead of calling the API every time. This helps in: • Faster UI • Better performance • Smoother user experience 🧠 𝗕𝗮𝘀𝗶𝗰 𝗶𝗱𝗲𝗮 𝗜 𝗳𝗼𝗹𝗹𝗼𝘄𝗲𝗱 1️⃣ Call the API 2️⃣ Store the response (state / ref / object) 3️⃣ Next time, check if data already exists 4️⃣ If yes → use it 5️⃣ If not → call the API again 🔄 𝗖𝗮𝗰𝗵𝗶𝗻𝗴 𝗶𝘀 𝗿𝗲𝗮𝗹𝗹𝘆 𝘂𝘀𝗲𝗳𝘂𝗹 𝗶𝗻 𝗰𝗮𝘀𝗲𝘀 𝗹𝗶𝗸𝗲 ✔️ Pagination ✔️ Infinite scroll ✔️ Navigating back and forth ✔️ Avoiding duplicate API calls This small change makes a 𝗯𝗶𝗴 𝗱𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝗰𝗲 𝗶𝗻 𝗿𝗲𝗮𝗹-𝘄𝗼𝗿𝗹𝗱 𝗮𝗽𝗽𝘀. 📸 I’ve attached a small code snippet showing: • Simple in-memory caching • Avoiding repeated API calls 👉 𝗡𝗲𝘅𝘁 𝘁𝗼𝗽𝗶𝗰𝘀 𝗜’𝗺 𝗽𝗹𝗮𝗻𝗻𝗶𝗻𝗴: • Pagination vs Infinite Scroll (interview point of view) • Intro to React Query (why it’s used in real projects) Would love to know — 𝘄𝗵𝗮𝘁 𝘀𝗵𝗼𝘂𝗹𝗱 𝗜 𝘀𝗵𝗮𝗿𝗲 𝗻𝗲𝘅𝘁? 👇 #ReactJS #FrontendDevelopment #ReactHooks #JavaScript #LearningInPublic #WebDevelopment

Useful React Hook 6/30 – useLocalStorageWithExpiry Have you ever faced a scenario where you wanted to hide a "New Feature" banner for exactly 24 hours, or cache an expensive API response for just 10 minutes, but realized LocalStorage has no built-in expiration? 🤔 Instead of writing complex date-checking logic every time, solve it once with this robust hook: useLocalStorageWithExpiry. Whether it's caching dashboard stats for 10 minutes, managing short-lived auth tokens, or hiding a "New Feature" banner for exactly 24 hours, this production-grade hook handles: ✅ Automatic Expiration: Data vanishes exactly when you want it to (TTL). ✅ Lazy Cleanup: Automatically wipes expired keys when accessed. ✅ Type Safety: Full TypeScript Generics support for strictly typed storage. ✅ SSR Safety: Prevents window is undefined crashes in Next.js/Gatsby. Why use this? ✨ Smart Caching: drastically reduce API calls by caching non-critical data. 🧹 Storage Hygiene: Keeps your application's footprint small by ensuring temporary data actually stays temporary. 🛡️ Fail-Safe Logic: Includes robust error handling (try/catch) for quota limits and JSON parsing errors. Link to gist: https://lnkd.in/giveJcPQ #ReactJS #WebDevelopment #TypeScript #Frontend #Hooks #CleanCode

Just built a localStorage demo with React! Explored how to efficiently store and retrieve user data using browser localStorage in React. This mini-project demonstrates: ✅ Serializing JavaScript objects with JSON.stringify() ✅ Storing user information in browser storage ✅ Retrieving and parsing data from localStorage ✅ Building practical client-side data persistence Perfect for understanding web storage fundamentals and creating offline-capable applications! 💾 #React #ReactJS #localStorage #WebDevelopment #Frontend #JavaScript #WebStorage #ReactJS101 #CodingProject #DeveloperLife #FullStackDevelopment #WebApps #BuildInPublic #TechJourney

𝗥𝗲𝗮𝗰𝘁 𝗖𝗼𝗻𝘁𝗲𝘅𝘁 𝗔𝗣𝗜 — 𝗨𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱𝗶𝗻𝗴 𝘁𝗵𝗲 𝗖𝗼𝗿𝗲 𝗖𝗼𝗻𝗰𝗲𝗽𝘁 The Context API allows React applications to share data across components without passing props manually at every level. Instead of sending data step-by-step through the component tree, we create a context, wrap the application with a Provider, and any nested component can access that shared value directly using 𝘂𝘀𝗲𝗖𝗼𝗻𝘁𝗲𝘅𝘁. In the diagram I shared: 𝘈𝘱𝘱 → 𝘗𝘢𝘳𝘦𝘯𝘵 → 𝘊𝘩𝘪𝘭𝘥 → 𝘎𝘳𝘢𝘯𝘥𝘊𝘩𝘪𝘭𝘥 The orange arrows represent the normal component hierarchy. The green arrows show how the context value flows directly from the Provider in App to GrandChild. Even though Parent and Child are in between, they are not responsible for passing the data. That’s the core idea of Context API — centralized state sharing with cleaner architecture. #ReactJS #FrontendDevelopment #JavaScript #WebDevelopment

𝗦𝘁𝗼𝗽 𝗚𝗹𝗼𝗯𝗮𝗹𝗶𝘇𝗶𝗻𝗴 𝗬𝗼𝘂𝗿 𝗦𝘁𝗮𝘁𝗲.🧠🛑 One of the most common architectural "smells" I see in large-scale React and Lit applications is an over-reliance on global state. Just because a piece of data is used in three different components doesn't mean it belongs in a global Redux or MobX store. In 2026, the mark of a Senior Engineer is knowing exactly where state should live to minimize re-renders and maximize maintainability. 𝗧𝗵𝗲 𝗚𝗿𝗲𝗮𝘁 𝗗𝗶𝘃𝗶𝗱𝗲: 𝗦𝗲𝗿𝘃𝗲𝗿 𝗦𝘁𝗮𝘁𝗲 𝘃𝘀. 𝗖𝗹𝗶𝗲𝗻𝘁 𝗦𝘁𝗮𝘁𝗲 1. 𝗦𝗲𝗿𝘃𝗲𝗿 𝗦𝘁𝗮𝘁𝗲 (𝗧𝗵𝗲 𝗥𝗲𝗺𝗼𝘁𝗲 𝗦𝗼𝘂𝗿𝗰𝗲): Data that comes from an API (User profiles, product lists, notifications). The Senior Approach: Stop manually managing loading, error, and data flags in your global store. Use a specialized tool like TanStack Query or SWR. They handle caching, revalidation, and background synchronization out of the box, keeping your local store clean. 2. 𝗖𝗹𝗶𝗲𝗻𝘁 𝗦𝘁𝗮𝘁𝗲 (𝗧𝗵𝗲 𝗨𝗜 𝗥𝗲𝗮𝗹𝗶𝘁𝘆): Data that only exists in the browser (Is this modal open? Which tab is active? Dark mode vs. Light mode). The Senior Approach: Keep this as local as possible. Use Component State first. If it needs to be shared, use Composition (passing components as props) or a lightweight Context provider. Reserve global stores only for truly global concerns like Authentication or Theme. The 3-Step State Audit:- ------------------------ 1. Is it persisted? If it’s from an API, it’s Server State. 2. Is it shared? If only two related components use it, use a common parent or Context. 3. Is it complex? If it’s just a toggle, useState is your best friend. The takeaway: Your global store shouldn't be a "junk drawer." A clean architecture separates the data we own (Client State) from the data we borrow (Server State). How has your state management strategy evolved since the "Redux for everything" era? 👇 #WebArchitecture #ReactJS #StateManagement #FrontendEngineering #Javascript #CleanCode #WebDevelopment

RS-X now works with React 🎉 I’m happy to share that RS-X can now be used with React. With RS-X, you can think in a more declarative way about your data and operations: - You define your data model - You define your operations via expressions - You bind the expressions to your data model - You can now just manipulate the data, and the expressions will update automatically You can see it directly in action on StackBlitz: https://lnkd.in/egRP2y7q For more details, check out the full article here: https://lnkd.in/eaf8auJb #React #Angular #TypeScript #JavaScript #FrontendDevelopment #WebDevelopment #StateManagement #ReactiveProgramming #OpenSource