Day 10: Optional Chaining & Null Safety — real bugs it prevents One of the most underrated features in TypeScript (and modern JavaScript) is optional chaining (?.). It looks small. But it saves you from some very real production bugs. 🚨 The Problem We’ve all written code like this: const userCity = user.address.city; Looks fine… until: ❌ user is null ❌ address is undefined ❌ API response changes 👉 Boom: "Cannot read property of undefined" 💡 The Fix — Optional Chaining const userCity = user?.address?.city; Now: ✅ No runtime crash ✅ Safely returns undefined ✅ Cleaner than multiple if checks 🧠 Real Bugs It Prevents ✔️ API responses missing fields ✔️ Optional form inputs ✔️ Feature flags not loaded ✔️ Nested config objects ✔️ User session data issues ⚡ Combine with Nullish Coalescing const city = user?.address?.city ?? "Unknown"; 👉 Default value only when null or undefined (not "" or 0) ❌ Without Optional Chaining if (user && user.address && user.address.city) { return user.address.city; } 👎 Verbose 👎 Hard to read 👎 Easy to miss a check 🎯 Key Takeaway Optional chaining is not just syntax sugar. It’s defensive programming built into the language. Less crashes. Cleaner code. Better developer sanity. 💬 Have you ever had a production bug because of undefined? Drop it below 👇 #TypeScript #JavaScript #WebDevelopment #Frontend #CleanCode #100DaysOfCode
Nikhil PC’s Post
More Relevant Posts
-
Day 12/100 of JavaScript 🚀 Today’s topic: async / await "async" and "await" provide a cleaner way to work with Promises and write asynchronous code that looks like synchronous code 📍Basic example async function getData() { const res = await fetch("https://lnkd.in/gCA7VyNQ"); const data = await res.json(); console.log(data); } 📍With error handling async function getData() { try { const res = await fetch("https://lnkd.in/gCA7VyNQ"); const data = await res.json(); console.log(data); } catch (err) { console.error(err); } } 🔑 Key points : - "async" makes a function return a Promise. - "await" pauses execution until the Promise resolves. - Makes code more readable than ".then()" chaining. async/await simplifies handling asynchronous operations while still using Promises under the hood. #Day12 #JavaScript #100DaysOfCode
To view or add a comment, sign in
-
🚀 map() vs. forEach(): Do you know the difference? The Hook: One of the first things we learn in JavaScript is how to loop through arrays. But using the wrong method can lead to "hidden" bugs that are a nightmare to fix. 🛑 🔍 The Simple Difference: ✅ .map() is for Creating. Use it when you want to take an array and turn it into a new one (like doubling prices or changing names). It doesn't touch the original data. ✅ .forEach() is for Doing. Use it when you want to "do something" for each item, like printing a message in the console or saving data to a database. It doesn't give you anything back. 💡 Why should you care? 1. Clean Code: .map() is shorter and easier to read. 2. React Friendly: Modern frameworks love .map() because it creates new data instead of changing the old data (this is called Immutability). 3. Avoid Bugs: When you use .forEach() to build a new list, you have to create an empty array first and "push" items into it. It’s extra work and easy to mess up! ⚡ THE CHALLENGE (Test your knowledge! 🧠) Look at the image below. Most developers get this wrong because they forget how JavaScript handles "missing" returns. What do you think is the output? A) [4, 6] B) [undefined, 4, 6] C) [1, 4, 6] D) Error Write your answer in the comments! I’ll be replying to see who got it right. 👇 #JavaScript #JS #softwareEngineer #CodingTips #LearnToCode #Javascriptcommunity #Programming #CleanCode #CodingTips
To view or add a comment, sign in
-
-
🚀 Day 968 of #1000DaysOfCode ✨ Types of Loops in JavaScript (Explained Simply) Loops are one of the most fundamental concepts in JavaScript — but choosing the right one can make a big difference in your code. In today’s post, I’ve explained the different types of loops in JavaScript in a simple and practical way, so you can understand when to use each one. From `for` and `while` to `for...of` and `for...in`, each loop has its own purpose depending on how you’re working with data. Using the right loop not only makes your code cleaner but also improves readability and performance in many cases. This is one of those basics that every developer uses daily — but mastering it helps you write much better code. If you’re working with arrays, objects, or complex data structures, this is something you should be confident about. 👇 Which loop do you use the most in your day-to-day coding? #Day968 #learningoftheday #1000daysofcodingchallenge #FrontendDevelopment #WebDevelopment #JavaScript #React #CodingCommunity #JSBasics
To view or add a comment, sign in
-
🧩 Demystifying the Node.js Event Loop: It's Not Just One Thread! Ever wondered what actually happens when you call setTimeout(() => {}, 1000)? Most people say "Node is single-threaded," but that’s only half the story. Here is the visual breakdown of how Node.js orchestrates asynchronous magic using libuv: 1. The Handoff (Main Thread) When you set a timer, the Main JS thread (V8) doesn't wait. It registers the callback and duration with libuv and moves on to the next line of code. 2. The Engine Room (libuv) This is where the heavy lifting happens. libuv maintains a Min-Heap—a highly efficient data structure that sorts timers by their expiration time. It puts the thread to "sleep" using OS-level polling (like epoll or kqueue) until the nearest timer is ready. 3. The Queue & The Tick Once the time arrives, libuv moves your callback into the Callback Queue. But it doesn't run yet! The Event Loop must cycle back to the "Timers Phase" to pick it up. ⚠️ The "Golden Rule" of Node.js Don't block the loop. If you run a heavy synchronous operation (like a massive while loop), the Event Loop gets stuck. Even if your timer has expired in the background, the Main Thread is too busy to check the queue. This is why a setTimeout(cb, 100) might actually take 5 seconds to fire if your main thread is congested. Key Takeaway: Node.js is fast because it offloads waiting to the OS via libuv, keeping the main thread free for execution. Keep your synchronous tasks light, and let the loop do its job! 🌀 #NodeJS #WebDevelopment #SoftwareEngineering #Backend #Javascript #ProgrammingTips
To view or add a comment, sign in
-
What To Know in JavaScript (2026 Edition). Part 1. Iterator Helpers (lazy data processing) JavaScript introduced Iterator Helpers — methods like .map(), .filter(), .take() directly on iterators. The goal is to avoid unnecessary intermediate arrays and improve performance. Instead of chaining operations that create arrays at every step, you get: → less memory usage → fewer computations → more predictable performance #frontend #webdev #javascript #performance
To view or add a comment, sign in
-
-
🚀 Exploring Blog 9 of the JS series: Map and Set in JavaScript. While developers often rely on objects and arrays, there are specific scenarios where Maps and Sets offer distinct advantages. Understanding when to use these data structures can enhance your coding practices. For insights into these use cases, check out the short blog linked below. Blog link: https://lnkd.in/gWRsZxy6 Hitesh Choudhary Piyush Garg Chai Aur Code #webdevcohort2026 #javascript #jsdatatypes
To view or add a comment, sign in
-
🚀𝐃𝐚𝐲 𝟏𝟒/𝟏𝟓 𝐨𝐟 𝐌𝐲 𝐉𝐚𝐯𝐚𝐒𝐜𝐫𝐢𝐩𝐭 𝐋𝐞𝐚𝐫𝐧𝐢𝐧𝐠 𝐒𝐞𝐫𝐢𝐞𝐬 Today I learned about Async / Await in JavaScript 💡 👉 Async/Await is used to handle asynchronous code in a cleaner and easier way. 👉 async makes a function return a promise 👉 await waits for the promise to resolve 📌 Example: function getData() { return new Promise((resolve) => { setTimeout(() => resolve("Data Loaded"), 1000); }); } 📌 Using async/await: async function fetchData() { let result = await getData(); console.log(result); } fetchData(); 👉 Output after 1 second: Data Loaded 👉 Async/Await makes code look like normal synchronous code 💻✨ 💬 Question: Do you prefer Promises (.then) or Async/Await? Let’s learn together 🚀 #JavaScript #WebDevelopment #LearningInPublic #Day14 #FrontendDevelopment
To view or add a comment, sign in
-
-
You add TypeScript to the project. Half the types are any. You basically wrote JavaScript with some extra syntax. TypeScript doesn't make your code safer. You do. And using any turns off the whole tool. Here's what most people miss: any doesn't stay where you put it. It spreads. function getUser(id: string): any { return api.fetch("/users/" + id); } const user = getUser("123"); const name = user.name; const upper = name.toUpperCase(); Every variable in this chain is any. No autocomplete, no safe changes, no errors caught before release. One any at the start shuts down the whole process. This is type erosion. It acts like tech debt — hidden until it causes problems. Before you type any, ask yourself two questions. First question: Do I really not know the type? If the data comes from an API — describe its structure. A partial type is much better than any. Second question: Am I just avoiding a type error? The compiler warns you, and you ignore it. That's not a fix. It's just @ts-ignore with extra steps. Use unknown instead. It means "I don't know" but makes you check before using it. any trusts without question. unknown requires proof. If your code has more than 5% any, you're not really using TypeScript. You're just adding decorations to JavaScript. Run npx type-coverage. Look at the number. Then decide. any is not a type. It's a surrender. #TypeScript #Frontend #JavaScript #WebDev #SoftwareEngineering #CodeQuality
To view or add a comment, sign in
-
-
I used to work on a JavaScript codebase where… Every file looked like this 👇Wrapped inside a self-invoking function (IIFE). And honestly…It didn’t make sense to me at first. Why are we doing this? Then I started asking basic questions: 👉 Why do we even split code into multiple files? At a high level → separation of concerns + reusability. We write logic in one file → use it in another.That’s basically what a module system does in any language. Then the next question hit me: 👉 What does IIFE have to do with modules? Here’s the catch: JavaScript initially didn’t have a module system. No imports. No exports. So what happens? 👉 Everything runs in the global scope. Which means: My variables = global Your variables = global Third-party library variables = also global Now imagine same variable names… 💥 Collision. So how did developers deal with this? 👉 Using functions. Because functions in JavaScript create their own scope. So the idea became: Wrap everything inside a function→ invoke it immediately→ expose only what’s needed --> return statement const module = (() => { const p1 = () => {} const p2 = [] const exports = { x1: () => {}, x2: [] } return exports })() Now think about it: 👉 p1 and p2 → private👉 x1 and x2 → public Nothing leaks into global scope. That’s when it clicked for me. This is basically a manual module system. Before:→ CommonJS→ ES Modules Funny thing is… Today we just write: export const x1 = () => {} …but back then, people had to build this behavior themselves. It is not about how things work today but why they exist in the first place. BTW this pattern is called 🫴Revealing Module Pattern.👈 #JavaScript #WebDevelopment #CleanCode #DeveloperJourney #Coding #FrontendDevelopment
To view or add a comment, sign in
-
Subject - Common mistake while using fetch in JavaScript Many beginners (including me) try to do this: const data = await fetch('https://lnkd.in/gNBBq58S'); const json = await JSON.stringify(data); 🚫 This is wrong because fetch() returns a Response object, not actual JSON data. ✅ Correct approach: const data = await fetch('https://lnkd.in/gNBBq58S'); const json = await data.json(); ✔️ Lesson: Always use .json() to extract data from the response. Small mistake, but important for real-world projects. #javascript #webdevelopment #frontend #coding #learninpublic
To view or add a comment, sign in
-
Explore content categories
- Career
- Productivity
- Finance
- Soft Skills & Emotional Intelligence
- Project Management
- Education
- Technology
- Leadership
- Ecommerce
- User Experience
- Recruitment & HR
- Customer Experience
- Real Estate
- Marketing
- Sales
- Retail & Merchandising
- Science
- Supply Chain Management
- Future Of Work
- Consulting
- Writing
- Economics
- Artificial Intelligence
- Employee Experience
- Workplace Trends
- Fundraising
- Networking
- Corporate Social Responsibility
- Negotiation
- Communication
- Engineering
- Hospitality & Tourism
- Business Strategy
- Change Management
- Organizational Culture
- Design
- Innovation
- Event Planning
- Training & Development