Return vs Throw in JavaScript Error Handling

⚠️ STOP using any in TypeScript. It’s not flexibility… it’s silent technical debt. You’ve written this 👇 let data: any; Looks harmless. Feels fast. But here’s what you actually did: 🧨 You lose type safety — TypeScript stops protecting you. 🧩 You lose IntelliSense — your IDE can’t autocomplete or infer. 🕳️ You lose refactor confidence — renames and changes won’t propagate. 🐛 You gain runtime bugs — errors sneak past compile‑time checks. Using any is like: 🚗 Driving without a seatbelt 🧪 Skipping tests “just for now” 🧱 Removing guardrails from your code It works… until it doesn’t. 🧠 Why We Still Use It Be honest 👇 • “I’ll fix types later” • “API response is messy” • “This is just a quick hack” 👉 That “temporary” any? It never gets removed. ✅ What Senior Devs Do Instead They don’t avoid flexibility. They use safe flexibility 👇 ✔️ unknown → forces validation ✔️ generics <T> → reusable + type-safe ✔️ interface / type → clear data contracts ✔️ Partial<T> → safe optional updates ✔️ Record<K, V> → structured dynamic objects ⚡ Angular Reality Check ❌ Bad: getTickets(): any { return this.http.get('/api/tickets'); } ✅ Good: getTickets(): Observable<Ticket[]> { return this.http.get<Ticket[]>('/api/tickets'); } Now your: ✨ IDE helps you ✨ Compiler protects you ✨ Bugs get caught early 🧩 Golden Rule 👉 If you use any, you’re telling TypeScript: “Don’t help me. I’ll debug in production.” Where have you seen any create real problems? (or are you still using it 👀) 👇 Drop your experience 🔖 Save this before your next refactor #Angular #TypeScript #Frontend #CleanCode #WebDevelopment #SoftwareEngineering #JavaScript #DevCommunity

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

Day 5 ⚡ Async/Await in JavaScript — The Clean Way to Handle Async Code If you’ve struggled with .then() chains, async/await is your best friend 🚀 --- 🧠 What is async? 👉 Makes a function always return a Promise async function greet(){ return "Hello"; } greet().then(console.log); // Hello --- ⏳ What is await? 👉 Pauses execution until a Promise resolves function delay(){ return new Promise(res => setTimeout(() => res("Done"), 1000)); } async function run(){ const result = await delay(); console.log(result); } --- ⚡ Why use async/await? ✔ Cleaner than .then() chaining ✔ Looks like synchronous code ✔ Easier error handling --- ❌ Sequential vs ⚡ Parallel // ❌ Sequential (slow) const a = await fetchUser(); const b = await fetchPosts(); // ⚡ Parallel (fast) const [a, b] = await Promise.all([ fetchUser(), fetchPosts() ]); --- ⚠️ Error Handling try { const data = await fetchData(); } catch (err) { console.log("Error handled"); } --- 💡 One-line takeaway 👉 async/await = cleaner + readable way to handle Promises #JavaScript #AsyncAwait #WebDevelopment #Frontend #Coding #100DaysOfCode

🔥 Still fishing your API data with useEffect? 🎣 I was doing the same… One API call — but handling loading, errors, dependency arrays, and refetch issues 😵 It felt like more work than the actual feature. Then I switched to React Query ⚡ And everything just… worked. No manual fetching. No unnecessary state management. No headaches. Just clean, synced, and reliable data. 👉 Work smarter. Not harder. Stop fishing your data 🎣 Start using React Query ⚡ Follow for more 🚀 #ReactNative #ReactNativeDevelopers #MobileAppDevelopment #ReactJS #ReactQuery #WebDevelopment #FrontendDevelopment #JavaScript #100DaysOfCode #DevCommunity #CodingLife #SoftwareEngineering #Programming #LearnToCode #Developers #TechContent #MobileApp

Everything was working… until production said otherwise 😅 One of the trickiest bugs in JavaScript is when your code is technically correct… but finishes in the wrong order. Many developers think: “If I use async/await, I’m safe.” Sadly… no 😄 async/await makes code look clean. It does NOT control which request finishes first. That’s where race conditions begin. Simple example: User searches “React” → Request 1 starts Immediately searches “Node.js” → Request 2 starts If Request 1 finishes later, old data can replace the new result. Now your UI confidently shows… the wrong answer. Classic. Same thing happens in Node.js too: ✔ Multiple API calls updating the same data ✔ Parallel requests overwriting each other ✔ Background jobs fighting like siblings Everything runs. Everything breaks. How to avoid it: ✔ Cancel old requests ✔ Ignore stale responses ✔ Use request IDs ✔ Debounce fast actions ✔ Handle backend concurrency properly Big lesson: async/await is syntax. Correct execution order is architecture. Very different things. Good code is not just: “It runs on my machine.” Good code is: “It runs correctly in production.” 😄 Have you ever debugged a race condition bug that made you question your life choices? 👇 #JavaScript #NodeJS #AsyncAwait #RaceConditions #FrontendDevelopment #BackendDevelopment #SoftwareEngineering #WebDevelopment

⚡ A small bug taught me a big lesson about performance in React While working on a search feature, I noticed something strange… 👉 When users typed fast, the results were inconsistent 👉 Older API responses were overwriting newer ones At first, it looked like a simple issue… but it wasn’t. 🔍 The problem: Multiple API calls were being triggered simultaneously, and slower responses were replacing the latest data. 💡 The solution: I implemented better request handling using: ✔️ Debouncing user input ✔️ Cancelling previous API calls (AbortController) ✔️ Careful state management to avoid stale updates 🚀 Result: Smooth, accurate search results with no flickering or outdated data 📚 Key learning: Performance issues are often about data flow, not just UI. This felt like a real-world engineering problem where small details make a big difference. Have you faced similar issues in React or async handling? #ReactJS #JavaScript #FrontendDevelopment #WebPerformance #LearningInPublic #Coding

𝟵𝟵% 𝗼𝗳 𝗝𝗦 𝗱𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿𝘀 𝘄𝗿𝗶𝘁𝗲 𝗮𝘀𝘆𝗻𝗰 𝗰𝗼𝗱𝗲 𝗱𝗮𝗶𝗹𝘆. 𝗕𝘂𝘁 𝗺𝗼𝘀𝘁 𝗰𝗮𝗻'𝘁 𝗲𝘅𝗽𝗹𝗮𝗶𝗻 𝘄𝗵𝘆 𝗶𝘁 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝘄𝗼𝗿𝗸𝘀. 👇 I didn't either until I learned about the JavaScript Runtime Environment. Here's the mental model that changed everything for me: JavaScript by itself is just a language. Runtime = Engine + APIs + Event Loop 🔥 What's actually running under the hood: ⚙️ JS Engine (V8) → converts code to machine code 📞 Call Stack → runs functions one by one 🌐 Web APIs → setTimeout, DOM, fetch (NOT part of JS itself!) 📬 Callback Queue → stores async callbacks ⚡ Microtask Queue → Promises, higher priority 🔄 Event Loop → the brain connecting everything The flow: Code → Call Stack → Web APIs → Queue → Event Loop → Call Stack Right now, try this 👇 console.log("Start"); setTimeout(() => console.log("Async"), 0); console.log("End"); Output → Start, End, Async 🤯 Even with 0 ms delay, "Async" prints LAST. That's the Event Loop doing its job. 🧠 Interview tip: Q: Why can JS handle async if it's single-threaded? A: The Runtime provides Web APIs + Event Loop + Queues — not the language. If this helped, repost ♻️ to help another developer. Follow Amit Prasad for daily updates on JavaScript and DSA 🔔 💬 Comment: Did you know that setTimeout 0ms still runs last? #JavaScript #WebDevelopment #Frontend #NodeJS #100DaysOfCode #DSA #Developer #CodingLife #TechLearning

𝐃𝐚𝐲 1/30 – 𝐍𝐨𝐝𝐞.𝐣𝐬 𝐒𝐞𝐫𝐢𝐞𝐬: 𝐖𝐡𝐚𝐭 𝐍𝐨𝐝𝐞.𝐣𝐬 𝐫𝐞𝐚𝐥𝐥𝐲 𝐢𝐬 (𝐛𝐞𝐲𝐨𝐧𝐝 𝐭𝐡𝐞 𝐝𝐞𝐟𝐢𝐧𝐢𝐭𝐢𝐨𝐧) Most people say: 👉 “Node.js is a JavaScript runtime built on Chrome’s V8 engine.” That’s correct… but honestly, it’s not useful in real-world discussions. Let’s understand it like an engineer 💡 𝐍𝐨𝐝𝐞.𝐣𝐬 𝐢𝐬 𝐍𝐎𝐓 𝐣𝐮𝐬𝐭 𝐚 𝐫𝐮𝐧𝐭𝐢𝐦𝐞 — 𝐢𝐭’𝐬 𝐚𝐧 𝐞𝐯𝐞𝐧𝐭-𝐝𝐫𝐢𝐯𝐞𝐧, 𝐧𝐨𝐧-𝐛𝐥𝐨𝐜𝐤𝐢𝐧𝐠 𝐬𝐲𝐬𝐭𝐞𝐦 𝐝𝐞𝐬𝐢𝐠𝐧𝐞𝐝 𝐟𝐨𝐫 𝐡𝐚𝐧𝐝𝐥𝐢𝐧𝐠 𝐜𝐨𝐧𝐜𝐮𝐫𝐫𝐞𝐧𝐭 𝐨𝐩𝐞𝐫𝐚𝐭𝐢𝐨𝐧𝐬 𝐞𝐟𝐟𝐢𝐜𝐢𝐞𝐧𝐭𝐥𝐲. What does that mean? 1. It uses a 𝐬𝐢𝐧𝐠𝐥𝐞-𝐭𝐡𝐫𝐞𝐚𝐝𝐞𝐝 𝐞𝐯𝐞𝐧𝐭 𝐥𝐨𝐨𝐩 2. It delegates heavy tasks (I/O, network, file operations) to the system 3. It doesn’t wait… it keeps moving 🔁 𝐑𝐞𝐚𝐥-𝐰𝐨𝐫𝐥𝐝 𝐞𝐱𝐚𝐦𝐩𝐥𝐞: Imagine your backend API is: 1. Reading files 2. Calling external APIs 3. Querying databases In traditional blocking systems: ➡ One request waits for another In Node.js: ➡ Multiple requests are handled 𝐰𝐢𝐭𝐡𝐨𝐮𝐭 𝐰𝐚𝐢𝐭𝐢𝐧𝐠 🧠 𝐒𝐢𝐦𝐩𝐥𝐞 𝐚𝐧𝐚𝐥𝐨𝐠𝐲: Node.js is like a smart manager: Assigns tasks to workers Doesn’t sit idle Keeps taking new tasks ⚠️ 𝐁𝐮𝐭 𝐡𝐞𝐫𝐞’𝐬 𝐭𝐡𝐞 𝐭𝐫𝐮𝐭𝐡 𝐦𝐨𝐬𝐭 𝐭𝐮𝐭𝐨𝐫𝐢𝐚𝐥𝐬 𝐬𝐤𝐢𝐩: Node.js is NOT always the best choice. ❌ CPU-heavy tasks (like image processing, large calculations) can block the event loop ❌ Poor async handling can still cause performance issues 🔥 𝐅𝐫𝐨𝐦 𝐦𝐲 𝐞𝐱𝐩𝐞𝐫𝐢𝐞𝐧𝐜𝐞: In one of my projects, instead of processing everything synchronously, we used 𝐪𝐮𝐞𝐮𝐞-𝐛𝐚𝐬𝐞𝐝 𝐚𝐬𝐲𝐧𝐜 𝐩𝐫𝐨𝐜𝐞𝐬𝐬𝐢𝐧𝐠 (similar to Service Bus pattern). This helped us: ✔ Avoid API timeouts ✔ Handle large workloads ✔ Improve system scalability ✅ 𝐓𝐚𝐤𝐞𝐚𝐰𝐚𝐲: Node.js shines when: ✔ You have I/O-heavy applications ✔ You need high concurrency ✔ You design it with async patterns correctly 📌 Tomorrow (Day 2): 𝐃𝐞𝐞𝐩 𝐝𝐢𝐯𝐞 𝐢𝐧𝐭𝐨 𝐄𝐯𝐞𝐧𝐭 𝐋𝐨𝐨𝐩 (𝐭𝐡𝐞 𝐡𝐞𝐚𝐫𝐭 𝐨𝐟 𝐍𝐨𝐝𝐞.𝐣𝐬) #NodeJS #BackendDevelopment #JavaScript #FullStack #SoftwareEngineering #SystemDesign

𝗕𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝗮 #𝗩𝗶𝘀𝘂𝗮𝗹𝗟𝗼𝗴𝗶𝗰𝗘𝗻𝗴𝗶𝗻𝗲: 𝗠𝗼𝘃𝗶𝗻𝗴 𝗕𝗲𝘆𝗼𝗻𝗱 𝗦𝘁𝗮𝘁𝗶𝗰 𝗨𝗜 I’ve always been fascinated by "low-code" tools like Zapier, Node-RED and Mostly N8N, so I decided to build my own version from scratch. I’m excited to share a project I’ve been working on: 𝗔 𝗡𝗼𝗱𝗲-𝗕𝗮𝘀𝗲𝗱 𝗩𝗶𝘀𝘂𝗮𝗹 𝗣𝗿𝗼𝗴𝗿𝗮𝗺𝗺𝗶𝗻𝗴 𝗘𝗻𝗴𝗶𝗻𝗲. It’s not just a UI; it’s a fully functional execution environment where you can orchestrate live API workflows. 𝗧𝗵𝗲 𝗖𝗵𝗮𝗹𝗹𝗲𝗻𝗴𝗲: How do you let a user write code in a node, execute it safely, and make it "wait" for an API response before moving to the next node? 𝗧𝗵𝗲 𝗦𝗼𝗹𝘂𝘁𝗶𝗼𝗻: I built a custom execution engine using the AsyncFunction constructor. This allows each node to handle asynchronous tasks like fetch while passing data down the chain in real-time. 𝗞𝗲𝘆 𝗙𝗲𝗮𝘁𝘂𝗿𝗲𝘀: ✅ 𝗔𝘀𝘆𝗻𝗰 𝗡𝗼𝗱𝗲 𝗘𝘅𝗲𝗰𝘂𝘁𝗶𝗼𝗻: Full support for async/await inside every node. ✅ 𝗗𝗮𝘁𝗮 𝗢𝗿𝗰𝗵𝗲𝘀𝘁𝗿𝗮𝘁𝗶𝗼𝗻: Pass the output of a POST request directly into a DELETE node. ✅ 𝗟𝗶𝘃𝗲 𝗖𝗼𝗻𝘀𝗼𝗹𝗲 𝗜𝗻𝗷𝗲𝗰𝘁𝗶𝗼𝗻: I intercepted the global console.log to provide real-time feedback within the UI. ✅ 𝗗𝘆𝗻𝗮𝗺𝗶𝗰 𝗦𝘁𝗮𝘁𝘂𝘀 𝗧𝗿𝗮𝗰𝗸𝗶𝗻𝗴: Visual feedback (Pending/Success/Error) using React Flow's state management. In the demo below, you can see a full 𝗖𝗥𝗨𝗗 𝗹𝗶𝗳𝗲𝗰𝘆𝗰𝗹𝗲 using the DummyJSON API. The engine fetches a list, creates a new entry, updates it, and finally deletes it—all while animating the data flow. Next up: Adding persistent storage so users can save and share their logic flows! Github : https://lnkd.in/eK7h9vFc #ReactJS #TypeScript #ReactFlow #WebDevelopment #SoftwareEngineering #JavaScript #Programming React, Reactflow and Google

most developers don't know about the optional chaining operator gotcha. they use it everywhere. it silently hides bugs. the problem: optional chaining (?.) returns undefined if property doesn't exist. you think it's safe. bugs slip through. why it breaks: when you use optional chaining, you're not validating — you're hiding. undefined gets passed around. downstream code breaks. you spend 2 hours debugging something that should have failed immediately. the real issue: optional chaining makes bad data look safe. it lets undefined flow through your app like it's normal. the solution: validate early. fail loud. don't let undefined silently propagate. when to use optional chaining: - reading optional properties - not for safety - for convenience only when NOT to use it: - critical data paths - anything you depend on - anything that should always exist one rule: optional chaining is a convenience. validation is safety. use both. #reactjs #typescript #webdevelopment #buildinpublic #javascript