Unlock JavaScript Destructuring for Cleaner Code

JavaScript is single-threaded… yet handles async like a pro. 🤯 If you’ve ever been confused about how setTimeout, Promises, and callbacks actually execute then the answer is the Event Loop. Here’s a crisp breakdown in 10 points 👇 1. The event loop is the mechanism that manages execution of code, handling async operations in JavaScript. 2. JavaScript runs on a single-threaded call stack (one task at a time). 3. Synchronous code is executed first, line by line, on the call stack. 4. Async tasks (e.g., setTimeout, promises, I/O) are handled by Web APIs / Node APIs. 5. Once completed, callbacks move to queues (macro-task queue or micro-task queue). 6. Micro-task queue (e.g., promises) has higher priority than macro-task queue. 7. The event loop constantly checks: Is the call stack empty? 8. If empty, it pushes tasks from the micro-task queue first, then macro-task queue. 9. This cycle repeats continuously, enabling non-blocking behavior. 10. Result: JavaScript achieves asynchronous execution despite being single-threaded. 💡 Master this, and debugging async JS becomes 10x easier. #JavaScript #WebDevelopment #Frontend #NodeJS #EventLoop #AsyncProgramming #CodingInterview

🔍 JavaScript Bug You Might Have Seen (null vs undefined) You write this: let a; console.log(a); // ? let b = null; console.log(b); // ? Both look similar… But they are NOT the same. 💥 Output: undefined null Now here’s where it gets confusing 👇 console.log(null == undefined); // ? console.log(null === undefined); // ? 💥 Output: true false Wait… WHAT? 🤯 This happens because of how JavaScript treats them. 📌 What is undefined? 👉 A variable that is declared but NOT assigned a value 📌 What is null? 👉 A value that represents “intentional absence of value” (You explicitly set it) 📌 Then why this? null == undefined // true Because == does loose comparison 👉 It treats them as equal BUT: null === undefined // false Because === checks: ✔ Value ✔ Type 💡 Takeaway: ✔ undefined → JS gives it ✔ null → YOU assign it ✔ == → treats them equal ✔ === → they are different 👉 Use undefined for default/unassigned 👉 Use null when you intentionally want “no value” 🔁 Save this before it confuses you again 💬 Comment “null” if this clicked ❤️ Like for more JavaScript deep dives #javascript #frontend #codingtips #webdevelopment #js #developer

Why do we specifically pass 'props' into 'super(props)' in a React component constructor? It is one of those things many developers do out of habit without realizing the actual mechanism behind it. While calling 'super()' is a JavaScript requirement to initialize the 'this' keyword, passing 'props' is a very specific React requirement for the constructor phase. The reason is simple: visibility. When you call 'super(props)', you are telling the parent 'React.Component' class to initialize 'this.props' for you immediately. If you only call 'super()' without the argument, 'this.props' will be undefined inside the constructor. React eventually assigns props to the instance anyway, but that happens after the constructor has finished running. If your logic requires you to access a property or compute a state based on a prop right inside the constructor, forgetting the 'props' argument will crash your logic. You would be trying to read from a variable that hasn't been wired up to the instance yet. Even though modern React code bases have shifted to Functional Components where this ceremony is gone, the underlying logic of when data becomes available to an instance is a core part of the library’s history. It is a small detail that perfectly illustrates how React works under the hood. #ReactJS #Javascript #SoftwareEngineering #FrontendDevelopment #WebDev #CodingTips

🚀 JavaScript Output Prediction Challenge What will be the output? 🤔 💡 Important Behaviour: 👉 JavaScript executes code line by line 👉 The very first line throws the following: ❌ ReferenceError: a is not defined So in reality, the programme stops immediately and nothing else runs. 📌 Now, let’s understand what would happen inside the function (ignoring the first error): 👉 Before execution, JS does Hoisting (memory creation phase) Inside the function: var a → hoisted and initialized as undefined let b → hoisted but kept in Temporal Dead Zone (TDZ) (not accessible yet) 👉 Execution phase: "1:" → undefined (Because 'a' exists but not assigned yet) "2:" → ❌ ReferenceError (because b is in TDZ) After assignment: a = 10 b = 20 "3:" → 10 "4:" → 20 🔥 Core Concepts: JS has 2 phases → Memory Creation + execution. var → hoisted + usable as undefined let/const → hoisted but blocked by TDZ 💬 If you got this right, your JS fundamentals are solid 👇 #JavaScript #Hoisting #Frontend #CodingChallenge #WebDevelopment

JavaScript is easy. Until it isn't. 😅 Every developer has been there. You're confident. Your code looks clean. You hit run. And then: " Cannot read properties of undefined (reading 'map') " The classic JavaScript wall. Here are 7 JavaScript mistakes I see developers make constantly and how to fix them: 1. Not understanding async/await ⚡ → Wrong: | const data = fetch('https://lnkd.in/dMDBzbsK'); console.log(data); // Promise {pending} | → Right: | const data = await fetch('https://lnkd.in/dMDBzbsK'); | 2. Using var instead of let/const → var is function scoped and causes weird bugs → Always use const by default. let when you need to reassign. Never var. 3. == instead of === → 0 == "0" is true in JavaScript 😱 → Always use === for comparisons. Always. 4. Mutating state directly in React → Wrong: user.name = "Shoaib" → Right: setUser({...user, name: "Shoaib"}) 5. Forgetting to handle errors in async functions → Always wrap await calls in try/catch → Silent failures are the hardest bugs to track down 6. Not cleaning up useEffect in React → Memory leaks are real → Always return a cleanup function when subscribing to events 7. Treating arrays and objects as primitives → [] === [] is false in JavaScript → Reference types don't compare like numbers — learn this early JavaScript rewards the developers who understand its quirks. 💡 Which of these caught YOU off guard when you first learned it? 👇 #JavaScript #WebDevelopment #Frontend #FullStackDeveloper #React #Programming #CodingTips #Developer #Tech #Pakistan #LearnToCode #JS #SoftwareEngineering #100DaysOfCode #PakistaniDeveloper

🔍 JavaScript Quirk: this behaves differently than you think This is one of the most confusing parts of JavaScript 👇 const user = { name: "Avinash", greet: function () { console.log(this.name); } }; user.greet(); // ? ✅ Output: "Avinash" Here, this refers to the object calling the function. Now look at this 👇 const greet = user.greet; greet(); // ? 💥 Output: undefined Why? Because this is no longer bound to user. In this case, this refers to the global object (or undefined in strict mode). Now the tricky part 👇 const user = { name: "Avinash", greet: () => { console.log(this.name); } }; user.greet(); // ? 💥 Output: undefined Why? Arrow functions don’t have their own this. They inherit it from their surrounding scope. 🚨 NEVER use this inside arrow functions for object methods. 💡 Takeaway: ✔ this depends on HOW a function is called ✔ Regular functions → dynamic this ✔ Arrow functions → lexical this ✔ Arrow + this in methods = bug waiting to happen 👉 Master this = fewer hidden bugs 🔁 Save this for later 💬 Comment "this" if it clicked ❤️ Like if this helped #javascript #frontend #webdevelopment #codingtips #js #developer

🔍 JavaScript Behavior You Might Have Seen (Array methods: mutate vs not) You write this: const arr = [1, 2, 3]; const newArr = arr.push(4); console.log(arr); // ? console.log(newArr); // ? You expect: 👉 newArr to be a new array But you get: 👉 arr → [1, 2, 3, 4] 👉 newArr → 4 This happens because of mutating array methods 📌 What does “mutate” mean? 👉 It means changing the original array In this case: 👉 push() modifies arr directly 👉 And returns the new length (not a new array) Now look at this 👇 const arr = [1, 2, 3]; const newArr = arr.map(x => x * 2); console.log(arr); // ? console.log(newArr); // ? 👉 arr → [1, 2, 3] 👉 newArr → [2, 4, 6] This is a non-mutating method 👉 It creates a new array 👉 Original array stays unchanged 📌 Common mutating methods: ✔ push ✔ pop ✔ shift ✔ unshift ✔ splice ✔ sort ✔ reverse 📌 Common non-mutating methods: ✔ map ✔ filter ✔ slice ✔ concat ✔ reduce 📌 Real problem: You think you’re creating a new array… 👉 But you accidentally modify the original one 💡 Takeaway: ✔ Mutating methods change original array ✔ Non-mutating methods return a new array ✔ Always be careful when updating state (especially in React) 👉 One wrong method can break your logic silently 🔁 Save this for later 💬 Comment “array” if this made sense ❤️ Like for more JavaScript deep dives #javascript #frontend #codingtips #webdevelopment #js #developer

🔍 JavaScript Behavior You Might Have Seen (Function Declaration vs Expression) You write this: sayHi(); function sayHi() { console.log("Hello"); } 👉 Works perfectly ✅ Now try this: sayHello(); const sayHello = function () { console.log("Hello"); }; 👉 ReferenceError ❌ Same idea… same function… Why different behavior? This happens because of Hoisting 📌 What’s happening here? 👉 Function Declarations are fully hoisted So internally: function sayHi() { console.log("Hello"); } sayHi(); 👉 That’s why it works even before definition But for Function Expressions: const sayHello = function () {} 👉 This is treated like a variable (const) So internally: const sayHello; // not initialized (TDZ) sayHello(); // ❌ error 📌 Key Difference: ✔ Function Declaration 👉 Hoisted completely (can call before definition) ✔ Function Expression 👉 Not hoisted like function 👉 Behaves like variable 📌 Bonus case 👇 var sayHello = function () { console.log("Hello"); }; sayHello(); 👉 Works (because var is hoisted) BUT: sayHello(); // before assignment 👉 TypeError ❌ (not a function yet) 💡 Takeaway: ✔ Function declarations → fully hoisted ✔ Function expressions → behave like variables ✔ let/const → TDZ error ✔ var → undefined (then TypeError if called) 👉 Same function… different behavior based on how you write it 🔁 Save this before it confuses you again 💬 Comment “function” if this clicked ❤️ Like for more JavaScript deep dives #javascript #frontend #codingtips #webdevelopment #js #developer

Why do we need to call 'super(props)' in the constructor of a React component? JavaScript classes aren't magic. They are just syntactic sugar over prototypes. If you are still using (or have used) Class Components in React, you have likely typed 'super(props)' a thousand times. But do you actually know what happens if you forget it? In JavaScript, you cannot use the keyword 'this' in a constructor until you have called the parent constructor. Since your component extends 'React.Component', calling 'super()' is what actually initializes the 'this' object. If you try to access 'this.state' or 'this.props' before that call, JavaScript will throw a ReferenceError and crash your app. But why pass 'props' into it? React sets 'this.props' for you automatically after the constructor runs. However, if you want to access 'this.props' inside the constructor itself, you must pass them to 'super(props)'. If you just call 'super()', 'this.props' will be undefined until the constructor finishes execution. Most of us have moved to Functional Components where this isn't an issue. But understanding these fundamentals is what separates a developer who just writes code from one who understands the runtime. #ReactJS #Javascript #SoftwareEngineering #WebDevelopment #Coding #ProgrammingTips

🚀 JavaScript Event Loop Explained (A Must-Know Concept) If you've ever wondered why setTimeout(fn, 0) doesn’t run immediately or how JS handles async tasks while being single-threaded — this is where the Event Loop comes in. Let’s break it down 👇 🧠 1. JavaScript is Single-Threaded JS runs one thing at a time using a Call Stack. Functions are pushed → executed → popped Only synchronous code runs here 🌐 2. Web APIs (Browser Magic) When JS encounters async operations: setTimeout, fetch, DOM events 👉 They are handled outside JS by Web APIs Once done, they don’t go to the stack directly… 📬 3. Queues (Where async waits) There are 2 types of queues: 🔹 Microtask Queue (High Priority) Promise.then() queueMicrotask() MutationObserver 🔸 Macrotask Queue (Low Priority) setTimeout() setInterval() DOM events 🔄 4. Event Loop (The Brain) The Event Loop keeps checking: 1️⃣ Is Call Stack empty? 2️⃣ Run ALL Microtasks 🟢 3️⃣ Then run ONE Macrotask 🟡 4️⃣ Repeat 🔁 💡 Example: console.log(1); setTimeout(() => console.log(2), 0); Promise.resolve().then(() => console.log(3)); console.log(4); 📌 Output: 👉 1 → 4 → 3 → 2 🔥 Why? 1, 4 → synchronous → run first 3 → microtask → higher priority 2 → macrotask → runs last ⚡ Pro Tips ✔ Microtasks always run before macrotasks ✔ Even setTimeout(fn, 0) is NOT immediate ✔ Too many microtasks can block UI (⚠️ starvation) 🎯 Why You Should Care Understanding the Event Loop helps you: Write better async code Debug tricky timing issues Ace JavaScript interviews 💼 💬 If this clarified things, drop a 👍 or comment your doubts — happy to help! #JavaScript #WebDevelopment #Frontend #NodeJS #Coding #Programming #SoftwareEngineering