Mastering JavaScript with Promises and Async/Await

𝗪𝗲𝗹𝗰𝗼𝗺𝗲 𝘁𝗼 𝗗𝗮𝘆 𝟴 Have you ever seen JavaScript behave correctly… but still give the wrong output? 🤔 𝘉𝘦𝘧𝘰𝘳𝘦 𝘴𝘤𝘳𝘰𝘭𝘭𝘪𝘯𝘨, 𝘨𝘶𝘦𝘴𝘴 𝘵𝘩𝘦 𝘰𝘶𝘵𝘱𝘶𝘵 𝘰𝘧 𝘵𝘩𝘪𝘴 𝘴𝘪𝘮𝘱𝘭𝘦 𝘤𝘰𝘥𝘦 𝚏𝚘𝚛 (𝚟𝚊𝚛 𝚒 = 𝟷; 𝚒 <= 𝟹; 𝚒++) {  𝚜𝚎𝚝𝚃𝚒𝚖𝚎𝚘𝚞𝚝(() => {   𝚌𝚘𝚗𝚜𝚘𝚕𝚎．𝚕𝚘𝚐(𝚒);  }, 𝟷𝟶𝟶𝟶); } 𝗘𝘅𝗽𝗹𝗲𝗰𝘁𝗲𝗱 1, 2, 3 𝗔𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗿𝗲𝘀𝘂𝗹𝘁 4,4,4 𝗧𝗵𝗶𝘀 𝗶𝘀 𝗮 𝗰𝗹𝗼𝘀𝘂𝗿𝗲 𝗯𝘂𝗴 — 𝗼𝗻𝗲 𝗼𝗳 𝘁𝗵𝗲 𝗺𝗼𝘀𝘁 𝗰𝗼𝗺𝗺𝗼𝗻 (𝗮𝗻𝗱 𝗰𝗼𝗻𝗳𝘂𝘀𝗶𝗻𝗴) 𝗝𝗮𝘃𝗮𝗦𝗰𝗿𝗶𝗽𝘁 𝗽𝗶𝘁𝗳𝗮𝗹𝗹𝘀. 𝗪𝗵𝘆 𝗧𝗵𝗶𝘀 𝗛𝗮𝗽𝗽𝗲𝗻𝘀 • var is function-scoped • setTimeout creates a closure • All callbacks reference the same variable i • When they execute, the loop has already finished Closures don’t capture values — they capture references. 𝗧𝗵𝗲 𝗙𝗶𝘅 𝚏𝚘𝚛 (𝚕𝚎𝚝 𝚒 = 𝟷; 𝚒 <= 𝟹; 𝚒++) {  𝚜𝚎𝚝𝚃𝚒𝚖𝚎𝚘𝚞𝚝(() => {   𝚌𝚘𝚗𝚜𝚘𝚕𝚎．𝚕𝚘𝚐(𝚒);  }, 𝟷𝟶𝟶𝟶); } 𝗪𝗵𝘆 𝘁𝗵𝗶𝘀 𝘄𝗼𝗿𝗸𝘀: • let is block-scoped • Each iteration gets its own binding • Each closure remembers a different i 𝗬𝗼𝘂’𝗹𝗹 𝘀𝗲𝗲 𝘁𝗵𝗶𝘀 𝗽𝗮𝘁𝘁𝗲𝗿𝗻 𝗶𝗻: • Event handlers • Async loops • API callbacks • Timers • React effects If you don’t understand closures, You don’t see the bug — you just debug longer. #JavaScript #JSFundamentals #Closures #FrontendDevelopment #WebDevelopment #BugFixing #ReactJS #LearningInPublic

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 is a successful language, but its success comes with trade-offs. We've learned to live with silent coercions and runtime surprises. You write defensive code and add checks to avoid bugs. StrictJS asks a simple question: what if JavaScript values meant what they said? In this post, you'll see how StrictJS handles numbers and strings. JavaScript has one numeric type: Number. This simplifies the language but introduces behavior you can't trust. Consider these examples: -5 + 1 equals51- "5" - 1 equals 4 - 0.1 + equals 0.30000000000000004 These are not bugs, they are design decisions. They mean values change silently, types lie about intent, and errors show up late. In StrictJS, a number is not just a value. You get: - No implicit coercion - Explicit creation only - Operations fail fast - Intent matters more than convenience For example: - const a = StrictNumber(5) - const b = StrictNumber("5") will throw an error If something is a string, it stays a string. Operations are explicit: - a.add(1) will work - a.add("1") will throw a type error You might see this as strict, but that's the point. You'd rather see an error while writing code than debug it later. Silent numeric coercion can break long-lived systems. Financial calculations can drift, counters can misreport, and API boundaries can blur. In StrictJS, a string is always just a string. You get: - No automatic casting - Explicit conversion only For example: - const name = StrictString("Kenneth") - const age = StrictString("25") - age + 1 will throw an error - age.toNumber() will work StrictJS makes intent visible in code. When someone reads it later, there is no ambiguity about what is happening. Source: https://lnkd.in/gMfGPPv4

I used to think == and === were just “style choices” in JavaScript. They’re not. That assumption once caused a bug that took me way too long to trace. Examples like: 0 == false → true "" == 0 → true null == undefined → true [ ] == false → true made me pause and actually understand what’s happening. Loose equality (==) compares values after type conversion. Strict equality (===) compares value and type, no guessing, no surprises. The scary part? Code with == can look correct and still behave unexpectedly, especially with user input, API data, or conditionals. My biggest learning: Use === by default. Only reach for == when you clearly understand every conversion involved. Have you ever faced a weird bug because of ==? #JavaScript #FrontendDevelopment #WebDevelopment #LearningInPublic #DeveloperJourney

So, asynchronous operations are a must in JavaScript. It's all about handling API calls, file reading, and timers without freezing up your code. You gotta love Promises - they're like a status update on an operation, letting you know if it's complete or failed. Failed: it didn't work. Now, before Promises, JavaScript relied on callbacks, which, let's be honest, were a nightmare - think Callback Hell, where your code gets all tangled up. But Promises changed the game with their cleaner syntax, better error handling, and chainable operations. It's like having a roadmap for your async tasks. A Promise can be in one of three states: pending (waiting), fulfilled (success), or rejected (failure). Once it's fulfilled or rejected, it's settled - like a done deal. You can use .then() and .catch() to handle success and error, kinda like having a plan B. And the best part? Promises can be chained, so you can perform multiple async tasks without losing your mind. This way, you avoid callback hell and improve readability - your code's like a breath of fresh air. Check out this resource for more info: https://lnkd.in/g-s7f_8a #JavaScript #Promises #AsynchronousProgramming #CodingSolutions #AsyncTasks

One line of JavaScript can replace an entire if/else block. The ternary operator might be the “question” that your code needs. The formally named “Conditional (ternary) operator” goes by many common names including: a ternary, one-line conditional, and shorthand if/else. It’s a powerful bit of JavaScript that can help you cut down on some of your if statements. A ternary’s syntax is structured sort of like a question: condition ? valueIfTruthy : valueIfFalsy The condition is an expression whose value will come in as either truthy or falsy - no those aren’t typos. Truthy and falsy are values that when considered in a boolean context come back as true or false, respectively. All values are truthy except for: false, 0, -0, 0n, null, undefined, NaN, and document.all. Let’s take this syntax and apply it to a practice example, checking if the user is a Prime member. const isPrimeMember = true; const shippingTime = isPrimeMember ? "2 Days" : "7 Days"; // shippingTime = 2 Days If we didn’t use a ternary, our code might look something like this: const isPrimeMember = true; if (isPrimeMember) { shippingTime = "2 Days"; } else { shippingTime = "7 Days"; } This code is totally valid, but you can see that by using a ternary we’ve used 2 lines rather than 7. Once you get comfortable with ternaries, you’ll start spotting places where they make your code cleaner and easier to read. They show up everywhere - especially in React - so getting familiar with them early pays off fast.

🟨 𝗝𝗮𝘃𝗮𝗦𝗰𝗿𝗶𝗽𝘁 𝗗𝗮𝘆 𝟰𝟵: 𝗜𝗻𝘃𝗲𝗿𝘀𝗶𝗼𝗻 𝗼𝗳 𝗖𝗼𝗻𝘁𝗿𝗼𝗹 (𝗖𝗮𝗹𝗹𝗯𝗮𝗰𝗸𝘀 𝗣𝗿𝗼𝗯𝗹𝗲𝗺) In JavaScript, we often use callbacks to handle async tasks — API calls, timers, or events. But callbacks introduce a hidden issue called Inversion of Control. 🔹 𝗪𝗵𝗮𝘁 𝗶𝘀 𝗮 𝗖𝗮𝗹𝗹𝗯𝗮𝗰𝗸? A callback is a function passed to another function and executed later. 𝘴𝘦𝘵𝘛𝘪𝘮𝘦𝘰𝘶𝘵(() => { 𝘤𝘰𝘯𝘴𝘰𝘭𝘦.𝘭𝘰𝘨("𝘑𝘢𝘷𝘢𝘚𝘤𝘳𝘪𝘱𝘵"); }, 1000); 🔹 𝗪𝗵𝗮𝘁 𝗶𝘀 𝗜𝗻𝘃𝗲𝗿𝘀𝗶𝗼𝗻 𝗼𝗳 𝗖𝗼𝗻𝘁𝗿𝗼𝗹? When we pass a callback, we give control of our code to another function. We don’t control: • When it runs • How many times it runs • Whether it runs at all 🔹 𝗘𝘅𝗮𝗺𝗽𝗹𝗲 𝘢𝘱𝘪.𝘤𝘳𝘦𝘢𝘵𝘦𝘖𝘳𝘥𝘦𝘳(𝘤𝘢𝘳𝘵, 𝘧𝘶𝘯𝘤𝘵𝘪𝘰𝘯 () { 𝘢𝘱𝘪.𝘱𝘳𝘰𝘤𝘦𝘦𝘥𝘛𝘰𝘗𝘢𝘺𝘮𝘦𝘯𝘵(); }); Here: • proceedToPayment is our code • createOrder decides when it runs • Our callback executes only when the API decides, based on its internal logic or async events. This is Inversion of Control in action. 🔹 𝗪𝗵𝘆 𝗧𝗵𝗶𝘀 𝗜𝘀 𝗮 𝗣𝗿𝗼𝗯𝗹𝗲𝗺 • Unexpected behavior • Harder debugging • Leads to callback hell in large apps 🔹 𝗦𝗼𝗹𝘂𝘁𝗶𝗼𝗻 Promises and async / await keep control in our hands. 🔹 𝗞𝗲𝘆 𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆 Callbacks give control away. Promises bring it back. 💬 GitHub link in the comments for examples #JavaScript #Day49 #100DaysOfCode #Frontend

It’s Promise Day - so let’s talk about JavaScript Promises! A Promise is an object which represents the eventual completion (or failure) of an asynchronous operation and its resulting value. In simpler terms, it is a placeholder for a future value. A promise can be in one of the three states: 1. Pending 2. Fulfilled 3. Rejected A promise also has a result: 1. If fulfilled → it returns a value 2. If rejected → it returns a reason (error) A common real-world example is the browser’s fetch() API, which returns a Promise. Let's see the syntax for creating a Promise now. const p = new Promise((resolve, reject) => {   // executor console.log("Runs instantly"); }); An executor is a function to be executed by the Promise constructor. It receives two functions as parameters: resolveFunc and rejectFunc. Any errors thrown in the executor will cause the promise to be rejected, and the return value will be neglected. When a Promise is created, it immediately enters the Pending state and executes its executor function. Once resolve (fulfilled) or reject is called, the Promise becomes settled and its result is permanently stored. Understanding Promises is the foundation of modern JavaScript — because async/await, fetch, and most modern APIs build on top of them. #JavaScript

𝗪𝗵𝗲𝗻 𝗝𝗮𝘃𝗮𝗦𝗰𝗿𝗶𝗽𝘁 𝗗𝗲𝗰𝗶𝗱𝗲𝘀 𝗠𝗮𝘁𝗵 𝗜𝘀 𝗮 𝗦𝘂𝗴𝗴𝗲𝘀𝘁𝗶𝗼𝗻 2 + 0 = 20 6 + 6 = 66 𝗪𝗿𝗼𝗻𝗴? Not if you speak JavaScript. 𝗘𝘃𝗲𝗿𝘆 𝗝𝗦 𝗱𝗲𝘃’𝘀 𝗳𝗶𝗿𝘀𝘁 𝗿𝗲𝗮𝗰𝘁𝗶𝗼𝗻: “Hold on… what’s the type?” 👀 Because in JavaScript: "2" + 0 becomes "20" "6" + "6" becomes "66" The + operator multitasks Your assumptions don’t 🧠 JavaScript doesn’t guess intent. 𝗜𝘁 𝗳𝗼𝗹𝗹𝗼𝘄𝘀 𝗿𝘂𝗹𝗲𝘀: 𝗳𝗹𝗲𝘅𝗶𝗯𝗹𝗲, 𝗱𝗮𝗻𝗴𝗲𝗿𝗼𝘂𝘀 𝗿𝘂𝗹𝗲𝘀. 𝗪𝗵𝗮𝘁 𝗹𝗼𝗼𝗸𝘀 𝗹𝗶𝗸𝗲 𝗯𝗿𝗼𝗸𝗲𝗻 𝗺𝗮𝘁𝗵 𝗶𝘀 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆: 👉 implicit type coercion 👉 string concatenation 👉 logic doing exactly what you asked for 😅 𝗧𝗵𝗲 𝗿𝗲𝗮𝗹 𝗯𝘂𝗴 𝗶𝘀𝗻’𝘁 𝗝𝗮𝘃𝗮𝗦𝗰𝗿𝗶𝗽𝘁. It’s forgetting that inputs lie. 📌 𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆 𝗳𝗼𝗿 𝗱𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿𝘀: • Be explicit with types • Validate inputs early • Never assume + means addition JavaScript gives you freedom. And freedom, as usual, comes with consequences. 🤝 𝗘𝘃𝗲𝗿𝘆 𝗝𝗦 𝗱𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿 𝗹𝗲𝗮𝗿𝗻𝘀 𝘁𝗵𝗶𝘀 𝘁𝗵𝗲 𝗵𝗮𝗿𝗱 𝘄𝗮𝘆 𝗼𝗻𝗰𝗲. #JavaScript #TypeCoercion #FrontendDevelopment #ProgrammingHumor #CodingTips