Samir Telrandhe’s Post

Most React performance advice is wrong. Not because the patterns are bad but because developers apply them without understanding what React is actually doing. Here’s what I’ve learned: React.memo without useCallback is just theater. memo tells React: “Only re-render if prop references change.” But if you pass a new function reference on every render, memo does absolutely nothing. // ❌ Kills memo on every render <ProductCard onSelect={(id) => handleSelect(id)} /> // ✅ Actually works const handleSelect = useCallback((id) => { dispatch({ type: "SELECT", payload: id }); }, [dispatch]); useMemo has a cost use it surgically. React still performs dependency comparison on every render. For cheap computations, the memoization overhead can be higher than simply recalculating. Use useMemo only when: the computation is genuinely expensive the result is passed to a memoized child you’ve measured it, not assumed it Before reaching for memo or useMemo, ask: What is actually triggering the re-render? Can you eliminate the trigger instead of memoizing around it? Structural state changes beat memoization every time. What’s the nastiest React performance bug you’ve hit in production? #React #ReactJS #Frontend #TypeScript #WebDevelopment #MERN #JavaScript #SoftwareEngineering

React isn’t just a library—it’s a mindset. From breaking down complex UIs into reusable components to managing state with precision, React teaches you how to think in systems, not just screens. What looks like simple code on the surface is actually layers of logic, structure, and scalability working together behind the scenes. Just like any powerful tool, the real value of React isn’t in writing code—it’s in how you architect experiences. Build components. Think in flows. Design for scale. #ReactJS #FrontendDevelopment #WebDevelopment #JavaScript #SoftwareEngineering

🤔 useMemo and useCallback confuse almost every React developer. Here’s the clearest way to think about it 👇 🧠 Core idea: → useMemo = cache a VALUE → useCallback = cache a FUNCTION REFERENCE 💻 Example: // useMemo — don't recalculate unless deps change const total = useMemo(() => cart.reduce((sum, item) => sum + item.price, 0), [cart] ); // useCallback — don't recreate unless deps change const handleClick = useCallback(() => { doSomething(id); }, [id]); 🎯 When to use useCallback: When you pass a function to a React.memo’d child Without it 👇 ➡️ A new function is created every render ➡️ React.memo becomes useless ⚠️ Common mistake: Wrapping everything in useMemo / useCallback “just in case” 💡 Reality check: Both hooks have a cost Use them only when: ✔️ You’ve identified a real performance issue ✔️ You’ve actually measured it 📌 Rule: Premature optimization ≠ good engineering #ReactJS #Hooks #JavaScript #FrontendDev

🚀 Just checked out Vite 8 + AI… and honestly, it feels crazy fast. At first, I used to think Vite was just another dev server. But after exploring it more, it’s actually way more powerful. Here are a few things I noticed 👇 ⚡ Builds feel much faster — even big projects start quickly 🧠 Dependency handling seems smoother (less random issues 😅) 📦 SSR support is better now, which is pretty cool 🔌 Plugins are improving and easier to work with 🛠️ Overall dev experience feels cleaner and less frustrating 💻 One thing I really liked: Frontend errors now show directly in the VS Code terminal (Browser Forward Console). Earlier I had to check the browser console, but now everything is in one place — makes debugging much easier. 📂 Also, TypeScript path aliases are supported better now. No more messy imports like ../../components — cleaner and easier to manage. 💭 What I liked the most: Hot reload + fast builds = less waiting, more coding. Still exploring it, but Vite 8 definitely feels like a solid upgrade. If you're working with React, Vue, or modern JS — you might want to give it a try. Has anyone else tried Vite 8 yet? What do you think? #Vite #Frontend #JavaScript #WebDev #React #Vue

Mastering useState: The Most Important Hook in React If you're working with React, useState is one of the first hooks you learn — and also one you’ll use in almost every component you build. Yet many developers still use it incorrectly and run into stale state or unnecessary re-renders. useState allows you to add state to functional components. It returns an array with two values: the current state and a setter function. const [count, setCount] = useState(0); The real power (and common pitfall) comes when your new state depends on the previous state. Correct way: Using the functional updater (prev) => guarantees you always get the latest state, even when multiple updates happen quickly. A few best practices I always follow: Never mutate state directly. Always create a new object/array using the spread operator (...prev). Use computed property names [dynamicKey] when your key comes from a variable. Keep state as simple as possible. If your state object gets too complex, consider useReducer. I’ve seen many bugs disappear simply by switching from setState(newValue) to the functional form when the update relies on previous values. Whether you’re building a small UI or a complex audio/video player like the one I was recently working on, mastering useState patterns makes your code more predictable, cleaner, and easier to debug. What’s one useState trick or gotcha you’ve learned? Drop it in the comments #React #JavaScript #WebDevelopment #Frontend #CodingTips

🚀 Mastering React Hooks – A Game Changer for Modern Development React Hooks completely changed the way we build components. No more complex class components — everything is cleaner, more readable, and reusable. Here are some of the most powerful hooks I use daily: 🔹 useState – Manage state easily 🔹 useEffect – Handle side effects like API calls 🔹 useContext – Share data across components 🔹 useReducer – Better state management for complex logic 🔹 useRef – Access DOM elements directly 🔹 useMemo & useCallback – Optimize performance 💡 Hooks not only simplify your code but also improve scalability and maintainability. If you're working with React and still not fully using Hooks, you're missing out on a huge productivity boost! 👉 What’s your favorite React Hook and why? #ReactJS #WebDevelopment #Frontend #JavaScript #ReactHooks #SoftwareDevelopment #Coding

🔯 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

Most React devs are still managing rollback logic by hand in 2026. Here’s the one hook that eliminates it. Every time you build a like button, a follow toggle, or an add-to-cart — you repeat the same flow: update the UI, send the request, handle failure, then undo the change. It works. But it’s a lot of brittle code for something that should be straightforward. React 19 brings useOptimistic — UI updates immediately, and React restores the correct state automatically if the request fails. No try/catch. No manual undo logic. No extra useState. Just define your optimistic reducer and call addOptimistic(). ❌ useState approach Two separate states, a try-catch, manual rollback on error. Doubles your code for every optimistic interaction. Fragile and tedious to maintain at scale. ✅ useOptimistic Declare once. UI updates instantly. React auto-reverts to real state if the action fails — no catch block, no manual rollback, no extra useState. Golden rule: If your UI needs to feel fast but can fail, avoid useState — use useOptimistic and let React handle it. #react #webdev #frontend #javascript #reactjs #coding #softwareengineering #devtips #ReactTips

Ever clicked two dropdowns and both stayed open at the same time? 😾 Looks unprofessional. Feels broken. Users hate it. Here is how I fixed it in React with just 2 lines : 👉 When Explore opens → force "Degree" dropdown to close onClick={() => {  setIsExploreMenuOpen(!isExploreMenuOpen);  setIsDegreeMenuOpen(false); // ← this one line does it }} 👉 When Degree opens → force "Explore" dropdown to close onClick={() => {  setIsDegreeMenuOpen(!isDegreeMenuOpen);  setIsExploreMenuOpen(false); // ← same idea }} The logic is simple: When you open something → explicitly close everything else. React does not do this automatically. You have to tell it exactly what to close. Small detail. Big difference in user experience. #react #nextjs #javascript #webdevelopment #tailwindcss #buildinpublic #frontenddevelopment

You wrapped your component in React.memo… but it still re-renders 🤔 I ran into this more times than I’d like to admit. Everything looks correct. You’re using React.memo. Props don’t seem to change. But the component still re-renders on every parent update. Here’s a simple example: const List = React.memo(({ items }) => { console.log('List render'); return items.map(item => ( <div key={item.id}>{item.name}</div> )); }); function App() { const [count, setCount] = React.useState(0); const items = [{ id: 1, name: 'A' }]; return ( <> <button onClick={() => setCount(count + 1)}> Click </button> <List items={items} /> </> ); } When you click the button the List still re-renders. At first glance, it feels wrong. The data didn’t change… so why did React re-render? The reason is subtle but important: every render creates a new array. So even though the content is the same, the reference is different. [] !== [] And React.memo only does a shallow comparison. So from React’s perspective, the prop did change. One simple fix: const items = React.useMemo(() => [ { id: 1, name: 'A' } ], []); Now the reference stays stable and memoization actually works. Takeaway React.memo is not magic. It only helps if the props you pass are stable. If you create new objects or functions on every render, you’re effectively disabling it without realizing it. This is one of those bugs that doesn’t throw errors… but quietly hurts performance. Have you ever debugged something like this? 👀 #reactjs #javascript #frontend #webdevelopment #performance #reactperformance #softwareengineering #programming #coding #webdev #react #typescript