Mohamed Sharfiras’ Post

⚛️ A real-life React situation that taught me a valuable lesson! I was fetching data from an API inside my React component. Everything worked fine at first — until I noticed something strange… the API was being called again and again 😅 My first thought: “Is my API haunted?” 👻 Turns out, it was just me forgetting to add the dependency array in useEffect. Here’s what I learned 👇 ❌ Wrong: useEffect(() => { fetchData(); }); ✅ Correct: useEffect(() => { fetchData(); }, []); The empty [] tells React to run the effect only once when the component mounts — not after every render. Lesson learned: sometimes one missing pair of brackets can cause infinite chaos 😆 Every mistake in React makes me understand it better — one re-render at a time! 🚀 #ReactJS #MERNStack #FrontendDevelopment #WebDevelopment #CodingJourney #LearningByDoing

Ever get stuck wondering why your React state isn't updating when you think it should? I burned a good hour on this yesterday. I was calling `setFormData({...})` and then immediately trying to use the `formData` variable on the next line. Predictably, it was holding the stale state. 🤦♂️ It’s a fundamental concept, but easy to forget: state updates are 𝐚𝐬𝐲𝐧𝐜𝐡𝐫𝐨𝐧𝐨𝐮𝐬 𝐚𝐧𝐝 𝐛𝐚𝐭𝐜𝐡𝐞𝐝. Your component function doesn't re-run instantly, so the variable in your current scope won't change right away. ⏱️ The real source of truth is only available in the *next* render. This is why `useEffect` is your best friend for running logic after a state change. 💡 Always treat state as a snapshot in time. The update you schedule won't be visible until the component re-renders. Have you struggled with this before? #ReactJS #FrontendDevelopment #DeveloperTips

Still writing all your logic inside your React components? I’ve been there, and it gets messy fast. My "aha" moment came when a component hit 400 lines. It was a tangled mess of `useState` and `useEffect` hooks for fetching data, handling form state, and managing a timer. The real problem? It was impossible to test or reuse any of it. 🧠 The solution was simple: custom hooks. By extracting logic into functions like `useUserData()` or `useFormInput()`, my components became lean, readable, and focused only on the 𝐕𝐈𝐄𝐖. It’s a pattern that feels like a superpower for clean code. ⚡️ If you’re repeating stateful logic, extract it. Your future self will thank you. What small change made a huge impact in your workflow? #ReactJS #FrontendDevelopment #DeveloperTips

I Tried React 19, and Data Fetching Finally Feels Effortless I recently explored how React 19 handles data fetching, and it’s a total game-changer. No more useEffect, useState, or dependency arrays just to fetch one API. Now, everything happens with one simple hook —> use(). 🔍 What makes it special: - Fetch data directly inside render - React waits for the Promise before rendering - No flicker, no double renders, no extra setup 💡 Why it’s better: - No manual state management - No useEffect for fetching - No state just to hold API results - No dependency debugging - Works seamlessly with Suspense - Built-in error handling with ErrorBoundary 🔁 Refetching? Easier than ever - Change a value/parameter → React cancels the old request and runs a new one. - Errors are handled automatically by ErrorBoundary. React 19 makes async fetching cleaner, faster, and more predictable. Definitely a feature every React dev should explore! #React19 #ReactJS #WebDevelopment #FrontendDevelopment #JavaScript #ReactHooks #SoftwareEngineer

😤 “I wrapped it in useMemo... but the component is still slow!” I faced this while optimizing a React dashboard. I used useMemo and useCallback everywhere — but performance barely improved. Turns out, I was solving the wrong problem. 🧠 What’s Really Happening useMemo and useCallback don’t make code faster — they just avoid recalculations if dependencies don’t change. But if your dependency is always changing, memoization never kicks in. Example 👇 const data = useMemo(() => expensiveCalculation(filters), [filters]); If filters is a new object every render (like { type: 'active' }), useMemo recomputes anyway — no performance win. ✅ The Fix Stabilize your dependencies first. Use useState, useRef, or memoize higher up to prevent unnecessary object recreation. const [filters, setFilters] = useState({ type: 'active' }); Or extract stable references: const stableFilter = useMemo(() => ({ type: 'active' }), []); Then memoization actually works as intended ✅ 💡 Takeaway > useMemo is not magic. It’s only as good as the stability of your dependencies. Optimize data flow first, hooks second. 🗣️ Your Turn Have you ever overused useMemo or useCallback? What’s your go-to way to diagnose React re-renders? #ReactJS #WebDevelopment #PerformanceOptimization #FrontendDevelopment #JavaScript #CleanCode #CodingTips #DevCommunity #LearnInPublic

💡 React Tip of the Day! Ever faced this? 👇 Your child component triggers an API call, but you want to re-fetch the data after the parent completes some task — without moving all that logic up to the parent 😩 Here’s a simple, elegant trick 💫 Use the key prop to re-render the child! <ChildComponent key={refreshKey} /> Then in the parent: setRefreshKey(prev => prev + 1); 💥 Each time the key changes, React remounts the child component — triggering its useEffect (and your API call) again automatically. Why this rocks 🚀 ✅ No need to uplift or duplicate API logic ✅ Keeps child components self-contained ✅ Clean, predictable, and easy to manage A neat little trick to refresh data without refactoring half your tree! 😄 #ReactJS #WebDev #FrontendTips #CleanCode #ReactHooks

I Tried React 19, and Data Fetching Finally Feels Effortless I recently explored how React 19 handles data fetching, and it's a total game-changer. No more useEffect, useState, or dependency arrays just to fetch one API. Now, everything happens with one simple hook → use (). 🔍What makes it special: - Fetch data directly inside render - React waits for the Promise before rendering - No flicker, no double renders, no extra setup 💡Why it's better: - No manual state management - No useEffect for fetching - No state just to hold API results - No dependency debugging - Works seamlessly with Suspense - Built-in error handling with ErrorBoundary 🔁 Refetching? Easier than ever - Change a value/parameter → React cancels the old request and runs a new one. - Errors are handled automatically by ErrorBoundary. React 19 makes async fetching cleaner, faster, and more predictable. Definitely a feature every React dev should explore! #React19 #ReactJS #WebDevelopment #FrontendDevelopment #JavaScript #ReactHooks #SoftwareEngineer

🧠 If you're a front end dev and don’t fully get JSON yet… you’re flying blind. Here’s why JSON isn’t just data, it’s the backbone of your front end. It’s how your app talks to APIs, stores state, configures features, and passes info everywhere. JSON (JavaScript Object Notation) is universal, human-readable, and language-agnostic. But it’s also stricter than it looks. -No comments -No trailing commas -No functions -Duplicate keys? Undefined behaviour -Dates? Just plain strings -Parse errors? App crash 🧩 In JavaScript, we use: JSON.parse() // from string → object   JSON.stringify() // from object → string But you must be careful: ✅ Always wrap response.json() in try/catch ✅ Validate data (with JSON Schema or Zod) ✅ Align JSON contracts early with your backend ✅ Post-process dates or special types after parsing Why does it matter? Because strong JSON skills help you: -Decode API payloads confidently -Shape state & configs with clarity -Debug faster and write safer front end code 🚀 Want to dive deeper into front end best practices? 👉https://lnkd.in/gP7p5U8i #frontenddevelopment #webdevelopment #javascript #json #apidevelopment 

LLM dev tools keep steering straight into React. System prompts hardwire it. Generated code defaults to it. The result? A feedback loop. Tools crank out React, models get trained on more React, and newcomers inherit the bias. What’s changing: React isn’t just a framework anymore. It’s sliding into invisible infrastructure. That shift sidelines native platform features and chokes off room for alternatives. https://lnkd.in/diDDf6j7 --- Enjoyed this? Sign up 👉 https://faun.dev/join

🕐 Give me 2 minutes — I’ll help you understand how Node.js works under the hood. Node.js isn’t “just JavaScript on the server.” Here’s what really happens 👇 ⚙️ 1. Single Thread, Smart Brain Node runs on a single thread — but uses the Event Loop to handle thousands of requests efficiently. ⚡ 2. Event Loop Magic (The Real Hero) The Event Loop decides what runs and when. It processes tasks in phases, each with its own priority: 🕒 Timers → executes setTimeout & setInterval callbacks. ⚙️ I/O Callbacks → handles network and file events. 🧠 Idle/Prepare → internal housekeeping. 🚀 Poll → retrieves new I/O events, executes related callbacks. 🧩 Check → runs setImmediate callbacks. 🔁 Close → cleans up closed connections. 🧵 Microtasks (Promises & process.nextTick) These run between phases — meaning they get priority over almost everything else. That’s why promises often feel “faster” than timeouts. 🧩 3. libuv + Thread Pool Heavy operations (like file I/O or compression) are handled off-thread by libuv, keeping the main loop free. 🚀 4. Non-Blocking I/O = Speed Node isn’t multithreaded magic — it’s smart scheduling and async flow. Understanding this is the first step from coding Node apps to mastering backend performance. ⚡ #NodeJS #Backend #JavaScript #WebDevelopment #Engineering #EventLoop