DIVYA PANDRAJU’s Post

 You think you know React... until you have to clean up a third-party script. I had a major "Aha!" moment building my Financial dashboard project, and it's a perfect example of how React's declarative world meets imperative, real-world JavaScript. The Problem: I'm integrating TradingView's embeddable widgets, which aren't React components. This requires manually creating <script> tags and injecting them into a div using a useEffect hook. The Naive Approach: Just create the script in useEffect and let React unmount the div when it's done. Simple, right? Wrong. This creates massive memory leaks. The third-party script (the "tenant") running inside my div (the "house") has its own background processes: setIntervals, WebSockets, and global event listeners. When React unmounts the div (demolishes the house), it doesn't tell the tenant to clean up. The "ghost" tenant lives on, still fetching data and consuming memory. The Solution & The "Aha!" Moments: 1. The "Stale Ref" Problem: My first attempt at a cleanup function failed because ref.current is null when the cleanup runs! The Fix: You have to snapshot the ref's value inside the effect: const node = ref.current;. The cleanup function's closure then remembers this node, even after ref.current is nullified. 2. The "Tenant Eviction" Model: This was the real lightbulb moment. Why clean the div with node.innerHTML = "" if React is removing it anyway? The Fix: The cleanup is not for React. It's a signal for the third-party script. Setting innerHTML = "" is like "evicting the tenant." The script is built to detect this, triggering its own internal destroy() logic—clearing its timers, closing its connections, and actually preventing the memory leak. Takeaway: React manages its own lifecycle, but we are 100% responsible for the lifecycle of any imperative, non-React code we introduce. This dive was a powerful lesson in JavaScript closures, React's lifecycle, and robust memory management. #reactjs #javascript #webdevelopment #frontend #MERNstack #reacthooks #memorymanagement #learning #coding

💡 JavaScript Tip: The Magical length Property of Arrays 😎 Most developers know that array.length gives the number of elements… But do you know how powerful (and tricky) it actually is? Let’s explore 👇 --- 🔹 1. Length is not read-only const arr = [1, 2, 3, 4]; arr.length = 2; console.log(arr); // [1, 2] 👉 Setting length truncates the array! All elements beyond the new length are removed. --- 🔹 2. You can also extend the array const arr = [1, 2]; arr.length = 5; console.log(arr); // [1, 2, <3 empty items>] 👉 Empty slots are created (they’re not undefined, they’re missing). --- 🔹 3. Length doesn’t always mean “last index + 1” const arr = []; arr[5] = 42; console.log(arr.length); // 6 👉 Sparse arrays have holes — indexes 0 to 4 don’t exist, but length still counts the last index + 1. --- 🔹 4. Deleting items doesn’t reduce length const arr = [10, 20, 30]; delete arr[1]; console.log(arr.length); // 3 console.log(arr); // [10, <1 empty item>, 30] 👉 The hole remains — length ignores deletions! --- ⚡ Quick Recap: Operation Effect on length push() / unshift() Increases pop() / shift() Decreases delete arr[i] No change arr.length = n Trims or extends --- 💭 Takeaway: length is not just a property — it’s a controller of your array’s shape and size. Handle it carefully to avoid silent bugs! --- #JavaScript #WebDevelopment #Frontend #CodingTips #JSArrays

🌀 The useEffect Hook in React: The useEffect hook in React ⚛️ is used to handle side effects in functional components. Side effects are actions that affect something outside the scope of the current function — such as:🧱 updating the DOM, 🔄 setting up subscriptions, or ⏰ managing timers. 🧩 Purpose: It replaces old lifecycle methods like: 🏗️ componentDidMount 🔁 componentDidUpdate 🧹 componentWillUnmount  from class components. 🧠 Syntax: useEffect(() => {   // 🧾 Code to run   return () => {     // 🧹 Cleanup code   }; }, [dependencies]); 📘 Parameters Explained: ➡️ Effect Function ⚙️ – Contains the main logic that performs the side effect (e.g., API call or DOM manipulation).  ➡️ Cleanup Function 🧼 – An optional return function inside useEffect used to clean up resources such as event listeners or timers.  ➡️ Dependency Array 🧮 – Determines when the effect should re-run. 🧭 How the Dependency Array Works: 🔹No dependency array → Runs after every render 🔁  🔹 Empty array [ ] → Runs once after the first render 🏁  🔹 Array with values [a, b] → Runs when any listed value changes ⚡ ✨ Quick Tip: 💡 Keep your effects clean and focused — split multiple side effects into separate useEffect hooks for better readability and performance. hashtag #React #Redux #Javascript #WebDevelopment #Frontend #LearnToCode #UI

🧠 Understanding Closures in JavaScript — The Hidden Superpower 💪 Ever wondered how a function remembers the variables from where it was created — even after that outer function has finished running? That’s the magic of Closures ✨ ⸻ 🧩 What is a Closure? A closure is formed when an inner function remembers and accesses variables from its outer function’s scope, even after the outer function has returned. Example 👇 function counter() { let count = 0; return function () { count++; console.log(count); }; } const increment = counter(); increment(); // 1 increment(); // 2 increment(); // 3 🧠 Even though counter() has finished executing, the inner function still remembers count. That’s a closure in action! ⸻ 💡 Why Do We Need Closures? Closures are not just theory — they’re practically everywhere in modern JavaScript 👇 ✅ Data privacy: They help you create private variables that can’t be accessed directly. ✅ State management: Perfect for functions that need to “remember” something between calls (like counters, timers, etc.). ✅ Callbacks & event handlers: Closures keep access to variables even after asynchronous operations complete. ✅ Encapsulation: They let you structure code neatly without polluting the global scope. ⸻ 🧭 Real-life analogy Think of a closure like a backpack 🎒 — When a function leaves its home (outer scope), it carries a backpack full of the variables it might need later. No matter where it goes, it can still use what’s inside that backpack. ⸻ ⚡ TL;DR A closure is when a function “remembers” the variables from the place it was created — even after that place is gone. They make JavaScript powerful, modular, and secure. ⸻ 💬 What’s your favorite real-world use of closures — data privacy, memoization, or event handling? Let’s share ideas below 👇 #JavaScript #WebDevelopment #Frontend #ReactJS #CodingTips

🧠 Why does let create a new closure in every loop iteration in JavaScript? Ever wondered why this works perfectly 👇 for (let i = 0; i < 3; i++) { setTimeout(() => console.log(i), 100); } // Output: 0, 1, 2 …but this doesn’t 👇 for (var i = 0; i < 3; i++) { setTimeout(() => console.log(i), 100); } // Output: 3, 3, 3 That’s not “compiler magic” — it’s actually defined in the ECMAScript specification itself. 📜 --- 📘 ECMA Definition From ECMA-262 §13.7.4.8 – Runtime Semantics: ForBodyEvaluation: > If the loop variable is declared with let or const, a new LexicalEnvironment is created for each iteration. The variable is copied (rebound) from the previous environment and used to evaluate the loop body in this new environment. --- 🔍 What This Means Every time the loop runs: JavaScript creates a new environment record (a fresh closure). The loop variable (i) is independent for that iteration. Each callback “remembers” its own copy of i. So effectively: var → single shared binding across all iterations. let / const → new closure per iteration. --- ✅ In short: let is not just about block scoping — it’s about creating predictable closures inside loops by design. #JavaScript #ECMAScript #Closures #Frontend #WebDevelopment #CodingTips #LearnInPublic

💥 JavaScript gotcha of the day: When you think you filled your array with different objects… but JavaScript had other plans 😅 const arr = Array(3).fill({}); // [{}, {}, {}] arr[0].hi = "hi"; console.log(arr); O/p// → [{ hi: "hi" }, { hi: "hi" }, { hi: "hi" }] You expected: [{ hi: "hi" }, {}, {}] but you got copy-paste chaos 🤯 🧠 Why? .fill({}) doesn’t create new objects — it fills the array with the same reference in memory. So arr[0].hi = "hi" updates all of them, because they’re all pointing to the same object! 🛠 Fix it: Use map() or Array.from() to create unique objects 👇 // ✅ distinct objects const arr = Array(3).fill().map(() => ({})); (or) const arr = Array.from({ length: 3 }, () => ({})); Now: arr[0].hi = "hi"; console.log(arr); // [{ hi: "hi" }, {}, {}] #JavaScript #CodingGotchas #WebDevelopment #Frontend #LearningEveryday #JSFun

When was the last time you consciously fought against “callback hell” in your JavaScript code? If it’s been a while, it’s probably because async/await has become such a game changer—making asynchronous code look synchronous, clean, and far easier to read. But here’s an interesting twist: **top-level await** is now officially part of modern JavaScript, and it’s transforming how we write modules, scripts, and test code. Traditionally, you could only use await inside async functions, but with top-level await, you can pause module execution directly at the root level without wrapping everything in `async function`. This feature is supported in most modern browsers and Node.js (from v14.8+), and it unlocks some exciting possibilities. Imagine loading data or initializing resources right when your module runs, something like: ```js const response = await fetch('https://lnkd.in/gwifyc_J'); const config = await response.json(); console.log('Config loaded:', config); ``` No async wrapper needed! This makes initialization scripts and module loading much more straightforward. It also improves readability for complex dependency chains because modules can wait on promises before exporting values. A few quick tips when using top-level await: - The module that uses top-level await becomes asynchronous itself. So, other modules importing it will implicitly wait until the awaited code completes. - Avoid blocking too long at the top level, or your app's startup may slow down. - It’s perfect for scripts or small initialization routines, especially in Next.js, ESM-based projects, or serverless functions. Seeing this in action can change how you architect your app startup logic or handle configuration loading. No more boilerplate async wrappers cluttering your code! So, if you’re still wrapping everything in `async function main() { ... }` just to use await, give top-level await a try. Cleaner, simpler, and modern JavaScript at its best. Who else is excited to use this feature in production? Drop your thoughts or experiences below! #JavaScript #ESModules #AsyncAwait #WebDevelopment #ModernJS #CodingTips #TechTrends #SoftwareEngineering

🧩 Custom Hooks: The Hidden Superpower of React When React introduced hooks, it wasn’t just another API — it was a quiet revolution. ⚡ Before hooks, we wrote class components that grew like wild forests. Logic was tangled across lifecycles, duplicated, or hidden behind HOCs. Then came this little thing called useSomething(). Suddenly, we could extract logic like Lego blocks. 💡 The moment I truly understood React wasn’t when I learned useEffect. It was when I realized I could write my own. function useOnlineStatus() {  const [isOnline, setIsOnline] = useState(navigator.onLine);  useEffect(() => {   const updateStatus = () => setIsOnline(navigator.onLine);   window.addEventListener('online', updateStatus);   window.addEventListener('offline', updateStatus);   return () => {    window.removeEventListener('online', updateStatus);    window.removeEventListener('offline', updateStatus);   };  }, []);  return isOnline; } That’s not a utility — that’s architecture in disguise. Hooks make behavior composable, predictable, and testable. The biggest mistake developers make? Using built-in hooks forever but never writing their own. Once you start thinking in custom hooks, you stop building components — and start designing systems of logic. #ReactJS #Hooks #FrontendDevelopment #CleanCode #JavaScript #WebArchitecture #ReactDesignPatterns #SystemDesign

A clean To-Do List is more than just a list! I just wrapped up this project, and the key challenge was handling the task reordering logic using pure React state array manipulation (no third-party drag-and-drop library!). The moveTaskUpside and moveTaskDownside functions specifically use array destructuring for an efficient swap: [arr[index-1], arr[index]] = [arr[index], arr[index-1]]. This helped reinforce concepts like immutability when updating state with setTasks. Tech Stack: React (useState) and CSS for the responsive, gradient-based UI. See it live: [Insert your Netlify Link here: https://lnkd.in/giuiwv-i] Let me know your thoughts on the approach! 👇 #ReactDevelopment #JavaScript #StateManagement #CodingProjects #Developer

💡 A powerful (and often underrated) use case for useRef in React useRef isn’t just about accessing DOM elements — it quietly solves one of the most important problems in React: preserving mutable values across re-renders without triggering re-renders. A classic example is a stopwatch ⏱️ const timerRef = useRef(null); const start = () => { timerRef.current = setInterval(() => { setSeconds((s) => s + 1); }, 1000); }; const stop = () => { clearInterval(timerRef.current); }; If we used a normal variable like let timer, React would reset it to null after every re-render (since the component function runs again). The result? Your “Stop” button wouldn’t actually stop the timer — the interval would keep running in the background. useRef prevents that by giving you a stable place to store such values — perfect for things like: Intervals / timeouts WebSocket or media stream instances Storing previous values Keeping track of imperative API references It’s one of those hooks that doesn’t re-render the UI, but silently keeps your logic rock solid. ⚙️✨ Sometimes, the most powerful tools are the quiet ones. #ReactJS #FrontendDevelopment #WebDev #JavaScript #useRef