JavaScript Equality: Understanding == and ===

Understanding why Promise.all() needs an array in JavaScript Many developers try this and get confused 👇 ❌ Wrong way Promise.all(p1, p2); ✅ Correct way Promise.all([p1, p2]); 🤔 Why does this happen? Promise.all() accepts only ONE argument, and that argument must be an iterable (most commonly an array). 👉 An array allows JavaScript to loop through multiple promises and wait for all of them to resolve.  ✅ Working example let p1 = new Promise((resolve) => {   resolve(1); }); let p2 = new Promise((resolve) => {   resolve(2); }); Promise.all([p1, p2]) .then((data) => {   console.log(data); // [1, 2] }); ❌ Why `Promise.all(p1, p2)` throws an error? When you write: Promise.all(p1, p2); JavaScript treats it as: Promise.all(p1); But p1 is a "Promise object", not an iterable like an array. So JS throws: TypeError: object is not iterable  🧠 Easy way to remember > Promise.all waits for a collection of promises, not individual ones Always wrap promises inside an array.  ⚠️ One more important thing If any promise rejects, Promise.all() immediately rejects. Promise.all([Promise.resolve(1), Promise.reject("Error")]) .catch(console.error); // Error 💡 Hope this helps someone avoid a common JavaScript pitfall! . . . . . #SRYTAL #JavaScript #Promises #WebDevelopment #Frontend #Learning #Promise.all #Growtogether

Understanding why `Promise.all()` needs an array in JavaScript Many developers try this and get confused 👇 ❌ Wrong way Promise.all(p1, p2); ✅ Correct way Promise.all([p1, p2]); 🤔 Why does this happen? Promise.all() accepts only ONE argument, and that argument must be an iterable (most commonly an array). 👉 An array allows JavaScript to loop through multiple promises and wait for all of them to resolve.  ✅ Working example let p1 = new Promise((resolve) => {   resolve(1); }); let p2 = new Promise((resolve) => {   resolve(2); }); Promise.all([p1, p2]) .then((data) => {   console.log(data); // [1, 2] }); ❌ Why `Promise.all(p1, p2)` throws an error? When you write: Promise.all(p1, p2); JavaScript treats it as: Promise.all(p1); But p1 is a "Promise object", not an iterable like an array. So JS throws: TypeError: object is not iterable  🧠 Easy way to remember > Promise.all waits for a collection of promises, not individual ones Always wrap promises inside an array.  ⚠️ One more important thing If any promise rejects, Promise.all() immediately rejects. Promise.all([Promise.resolve(1), Promise.reject("Error")]) .catch(console.error); // Error 💡 Hope this helps someone avoid a common JavaScript pitfall! . . . . . #SRYTAL #JavaScript #Promises #WebDevelopment #Frontend #Learning #Promise.all #Growtogether

One of the most common bugs in JavaScript and React comes from copying objects the wrong way 😅 Shallow Copy vs Deep Copy In JavaScript, when you copy an object using the spread operator (...), you are only creating a shallow copy. Example: ``` const user = { name: “Ali”, skills: [“JS”, “React”] }; const copy = { …user }; copy.skills.push(“Node”); console.log(user.skills); // [“JS”, “React”, “React”, “Node”] ``` Why did the original object change? Because: • name was copied • but skills is still pointing to the same array in memory Both user.skills and copy.skills reference the same place. To create a real independent copy, use: const deepCopy = structuredClone(user); Now changing deepCopy will not affect user. 📌 In React, this mistake can cause: • state bugs • missing re-renders • very confusing UI issues Understanding how memory and references work is a game changer. #JavaScript #React #Frontend #WebDevelopment #Programming

So, "this" in JavaScript is a total wild card. You ask 10 devs, you get 10 different answers. It's a bug magnet, especially for those coming from other languages where "this" is straightforward. It's simple: "this" is all about how a function is called, not where it's defined. That's the root of most confusion. Now, let's break it down - there are four binding rules. Default binding: "this" goes global (or undefined in strict mode) when a function is called on its own. Implicit binding:this is the object before the dot when a function is called as a method. Explicit binding: you can setthis using call(), apply(), or bind(). And new binding: "this" is bound to the new object when you call a function with new. Arrow functions are different - they lexically bind "this" from their surrounding scope. So, losing "this" in callbacks is a common gotcha - just use arrow functions or bind(). In React, class components need binding in the constructor or arrow functions. But functional components with hooks? They avoid "this" altogether. The key takeaways: "this" depends on the function call, not definition. Arrow functions inherit "this" lexically. And in React, event handlers need binding because they're called as standalone functions. Check out this explanation for more: https://lnkd.in/gYxS529W #JavaScript #ThisKeyword #React

So, "this" in JavaScript is a total wild card. You ask 10 devs, you get 10 different answers. It's a bug magnet, especially for those coming from other languages where "this" is straightforward. It's simple: "this" is all about how a function is called, not where it's defined. That's the root of most confusion. Now, let's break it down - there are four binding rules. Default binding: "this" goes global (or undefined in strict mode) when a function is called on its own. Implicit binding:this is the object before the dot when a function is called as a method. Explicit binding: you can setthis using call(), apply(), or bind(). And new binding: "this" is bound to the new object when you call a function with new. Arrow functions are different - they lexically bind "this" from their surrounding scope. So, losing "this" in callbacks is a common gotcha - just use arrow functions or bind(). In React, class components need binding in the constructor or arrow functions. But functional components with hooks? They avoid "this" altogether. The key takeaways: "this" depends on the function call, not definition. Arrow functions inherit "this" lexically. And in React, event handlers need binding because they're called as standalone functions. Check out this explanation for more: https://lnkd.in/gYxS529W #JavaScript #ThisKeyword #React

🚀 JavaScript Hoisting: A Practical Breakdown Hoisting describes how JavaScript processes declarations before code execution. What actually gets hoisted — and how — depends on the type of declaration, which is why different keywords behave differently. 🔹 Function Declarations Function declarations are fully hoisted, so they can be called before they appear in the code. greet(); // Works function greet() {  console.log("Hello!"); } 🔹 var Variables var declarations are hoisted, but their values are not. Before assignment, the variable is undefined. console.log(count); // undefined var count = 3; 🔹 let Variables let is hoisted but placed in the Temporal Dead Zone (TDZ). Accessing it before declaration throws an error. console.log(total); // ReferenceError let total = 10; 🔹 const Variables const behaves like let in terms of hoisting and TDZ, but its value cannot be reassigned. console.log(rate); // ReferenceError const rate = 5; 🔹 Function Expressions & Arrow Functions These are hoisted only as variables, not as functions. sayHi(); // TypeError const sayHi = () => {  console.log("Hi!"); }; #JavaScript #Hoisting #WebDevelopment #Frontend #CleanCode #Developers

🧠 Most JavaScript devs argue over this — and that’s the point 👀 (Even seniors don’t agree immediately) No frameworks. No libraries. Just how JavaScript actually schedules work. 🧩 Output-Based Question (Event Loop: microtasks vs macrotasks) console.log("A"); setTimeout(() => {  console.log("B"); }, 0); Promise.resolve().then(() => {  console.log("C"); }); queueMicrotask(() => {  console.log("D"); }); console.log("E"); ❓ What will be printed — in the correct order? ❌ Don’t run the code 🧠 Think like the JavaScript engine A. A → E → C → D → B B. A → C → D → E → B C. A → E → D → C → B D. A → E → C → B → D 👇 Drop ONE option only (no explanations yet 😄) Why this matters Most developers know: Promises run before setTimeout But many don’t know: queueMicrotask runs before .then Console order ≠ execution intuition One wrong assumption = flaky UI or race bugs When fundamentals aren’t clear: async bugs feel random production issues are hard to reproduce debugging becomes guesswork Strong JavaScript developers don’t memorize outputs. They understand why the engine schedules work this way. 💡 I’ll pin the full breakdown after a few answers. #JavaScript #EventLoop #AsyncJavaScript #JSFundamentals #WebDevelopment #FrontendDeveloper #FullStackDeveloper #CodingInterview #DevCommunity #VibeCode 

So, you're trying to wrap your head around this weird thing in JavaScript. It's like, you write a function inside an object, and it's all good - it knows who it is. But then you pass it to another function, and suddenly it's like, "Wait, who am I again?" It's because "this" in JavaScript isn't a fixed label, it's more like a question. When the code runs, the function looks around and asks, "Who called me?" - and the answer is pretty simple, really. Just look to the left of the dot. If you see an object, that's who "this" is. No object? Thenthis is undefined. Here's the thing: if you call a function through an object, "this" is that object - makes sense, right? But if you call a function without an object,this is undefined. And then there are these two methods, .call() and .bind(), that can kind of forcethis to be a specific object. Use .call(), and it's like you're telling the function, "For this one time, you're this object" - it's a temporary thing. But use .bind(), and you're creating a new function that remembers its owner forever - it's like giving it a permanent identity. It's all about context, really. In JavaScript, your identity isn't about who you are, it's about who's holding you at the moment you speak - it's a pretty fluid thing. Check out this article for more on the secret life of JavaScript: https://lnkd.in/grANWBg6 #JavaScript #Identity #Coding

🚀 4 JavaScript Gotchas Every Developer Should Know JavaScript is powerful, but it comes with quirks that can surprise even experienced developers. Here are 4 key concepts I always keep in mind: 1️⃣ typeof Edge Cases Not everything is what it seems! For example, null is technically considered an object, and arrays are also objects. Always double-check the type before making assumptions. 2️⃣ == vs === JavaScript has both loose equality (==) and strict equality (===). Loose equality can produce unexpected results due to type coercion. To avoid bugs, I always prefer strict equality unless there’s a deliberate reason to coerce types. 3️⃣ Truthy & Falsy Values Some values like 0, null, undefined, NaN, or empty strings are considered falsy, while most other values are truthy. Understanding this helps write cleaner conditional checks and avoids surprises in logic. 4️⃣ Hoisting (Variables vs Functions) Declarations in JavaScript are conceptually moved to the top of their scope. Variables declared with var behave differently than let and const, and function declarations are fully hoisted. Knowing this helps predict code behavior and prevent runtime errors. ✅ Key Takeaways Always be aware of type quirks Prefer strict equality (===) Watch out for falsy values in conditionals Understand hoisting to avoid unexpected behavior Mastering these JavaScript “gotchas” will make your code more predictable, cleaner, and bug-free 💪 #JavaScript #WebDevelopment #Developers #Frontend #Backend #CodingTips #Learning

Why #JavaScript Logic Confuses Even Developers 🧠💥 JavaScript is powerful... but it loves to surprise you. Here's why: Type Coercion Magic ✨ "11" + 1 // "111" "11" - 1 // 10 •means string concatenation •forces number conversion Same values, wildly different results! +"" // 0 +{} // NaN +[] // 0 Loose vs Strict Equality ⚖️ 0 == "0" // true 😱 0 === "0" // false ✅ Truthy & Falsy Surprises 🤯 Boolean("0") // true Boolean([]) // true Boolean({}) // true Boolean(0) // false JavaScript auto-converts types to be "helpful"... but that flexibility breeds bugs. How Pros Avoid This (React Dev Edition) 🚀 • Always use === over == • Convert explicitly: Number(), String(), Boolean() • Ditch implicit coercion • Switch to TypeScript for type safety in your React/Next.js apps JS isn't broken—it's just too flexible. Save this cheat sheet! 📌 Comment "JS" if you've been bitten by this. 👇 #JavaScript #WebDevelopment #ProgrammingHumor #CodingLife #Frontend #Developer #codingirlben #React #DeveloperLife #ReactJS #CodingMemes #DevHumor